----MESSAGE-BEGIN---- [8709011500.AA21222@sneezy.lanl.gov] <1987090107001600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cpw%sneezy@LANL.GOV (C. Philip Wood) Newsgroups: comp.protocols.tcp-ip Subject: Help with broken TCP Message-ID: <8709011500.AA21222@sneezy.lanl.gov> Date: Tue, 1-Sep-87 11:00:16 EDT Article-I.D.: sneezy.8709011500.AA21222 Posted: Tue Sep 1 11:00:16 1987 Date-Received: Sat, 5-Sep-87 04:10:54 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 31 What follows is a TCP scenario observed on our local ethernet. The ftp application (A) has just pushed out the last data block to (B) and is closing the connection. The first FIN from (A) is lost. An ACK from (B) for the last data block arrives. Then there begins a conversation of FIN(A) then ACK(B) with longer and longer time intervals between each set of FIN(A)/ACK(B) as if the ACK is being dropped and a retransmit timer is backing off, firing and a FIN being sent. Notice that the sequence number set in the retransmitted FIN packets is one less than that set in the lost FIN packet. Are both peers broken or just the sender of the FINs? This is a tcpdump. I added an * to indicate the lost packet. (In case your curious, the packet is lost because of an inability to handle back to back packets on the part of B) 15:31:36.86 A > B: S -1063845887:-1063845887(0) win 4096 15:31:36.86 B > A: S 253698321:253698321(0) ack -1063845886 win 384 15:31:36.86 A > B: . ack 1 win 4096 15:31:37.12 A > B: P 1:146(145) ack 1 win 4096 15:31:37.12 A >* B: F 146:146(0) ack 1 win 4096 15:31:37.38 B > A: . ack 146 win 384 15:31:39.12 A > B: F 145:145(0) ack 1 win 4096 15:31:39.14 B > A: . ack 146 win 384 15:31:41.12 A > B: F 145:145(0) ack 1 win 4096 urg 1 15:31:41.14 B > A: . ack 146 win 384 15:31:45.12 A > B: F 145:145(0) ack 1 win 4096 urg 1 15:31:45.14 B > A: . ack 146 win 384 15:31:53.12 A > B: F 145:145(0) ack 1 win 4096 urg 1 and so on... Phil Wood (cpw@lanl.gov) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [737@ucdavis.UUCP] <1987090112193200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ccruss@ucdavis.UUCP (Russ Hobby) Newsgroups: comp.protocols.tcp-ip Subject: Re: Where can I find SLIP server for 4.2/3? Message-ID: <737@ucdavis.UUCP> Date: Tue, 1-Sep-87 16:19:32 EDT Article-I.D.: ucdavis.737 Posted: Tue Sep 1 16:19:32 1987 Date-Received: Sat, 5-Sep-87 04:44:09 EDT References: <8708311459.AA25432@oswego> Reply-To: ccruss@deneb.ucdavis.edu (Russ Hobby) Organization: University of California, Davis Lines: 65 Here at UC Davis this summer we have been working on a project to allow PCs to make dialup SLIP connections to the campus IP network. We are also working on abbreviated serial line IP (ASLIP) packeting that will make dialup IP networks more efficient. Here is how the system works. The user logs on to the host that is acting as the gateway, a 4.3 bsd system. He then types in the command "slip" and he becomes a host on the network. He can then use all the programs that come with the CMU/MIT PC/IP or Phil Karn's system. To make connecting to the network a little easier, we have written a program that will do the complete login automatically. The program has a user configurable script file that specifies a sequence of strings to send out the serial line and responses to wait for comming back. It has its own simple language with branching depending on if the correct response came back. The net result is that after the script has been set up, the user types in one command on the PC to connect to the network. Unlike some PC/IPs, our system assumes that each PC (or actually each user) has its own, permanent IP address. Security is provided by logon security on the gateway host. The IP address of the PC is associated with the usercode on the gateway host. The network connection for that PC's IP address can only be started from a user logged in with the correct usercode. The system also makes sure that the IP address is not already connected before making a new connection. The way we have set up IP address for the PCs is to have a separate subnet that contains all the PCs. This way the gateway host needs only to advertise that it is a route to that subnet and all the PCs are covered. In essence the gateway host is the network for all SLIP connections on that subnet. The abbreviated packets work on the assumption that the connecting computer is an end-node and will not be doing any routing. In this case many of the fields in the IP packet are unnecessary. ASLIP uses the minimum header size based on this assumption. With ASLIP the header size is either 8 or 4 bytes, much smaller than the standard 40 bytes. The host that is acting as the ASLIP gateway rebuilds the outgoing packets to legal IP packets before sending them out the network and abbreviates the incoming packets from the network. The login capabilities are currently working. I frequently connect my PC at home via dialup modems( one command "netcon") and use telnet, ftp, whois and smtp. Code for ASLIP is now being written and hopefully will be done by the end of September. At that point we will package up everything necessary to make it work and it will be available to anyone that is interested. Also there have been some terminal server vendors interested in this project. It should not be much work to turn a terminal server into an ASLIP or SLIP server and that would make it cheaper than using a VAX as the gateway. Plus there would not be as much maintainance and downtime with a simple server box. This Fall's project is to take the best of CMU's PC/IP, Phil Karn's IP and Stanford's PC/IP and make a PC package that has the networking interface and services(SMTP,FTP...) running in the background. Client software will run in foreground but will use the background interfaces for connection to the network. Russell Hobby Data Communications Manager U. C. Davis Computing Services BITNET: RDHOBBY@UCDAVIS Davis Ca 95616 UUCP: ...!ucbvax!ucdavis!rdhobby (916) 752-0236 INTERNET: rdhobby@ucdavis.ucdavis.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709012028.AA21355@sneezy.lanl.gov] <1987090112285400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cpw%sneezy@LANL.GOV (C. Philip Wood) Newsgroups: comp.protocols.tcp-ip Subject: Re: Help with broken TCP Message-ID: <8709012028.AA21355@sneezy.lanl.gov> Date: Tue, 1-Sep-87 16:28:54 EDT Article-I.D.: sneezy.8709012028.AA21355 Posted: Tue Sep 1 16:28:54 1987 Date-Received: Sat, 5-Sep-87 04:44:53 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 4.3BSD network bug (#9, tcp_output) had a fix for an undetected data loss during connection closing. This may well have fixed the data loss due to lost data segments, but, apparently it will cause the symptom I reported if the data segment with FIN is lost. If the test: if (flags & TH_FIN && tp->t_flags & TF_SENTFIN && len == 0) succeeds the #9 code decremented tp->sndnxt by one. Instead, I set tp->snd_nxt = tp->snd_una, and the symptom went away. I'm not saying this is a fix, but it may point more to the problem. Phil Wood (cpw@lanl.gov) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [233@mitisft.Convergent.COM] <1987090114041300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: andrew@mitisft.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Dialup SLIP (was Re: Where can I find SLIP server for 4.2/3?) Message-ID: <233@mitisft.Convergent.COM> Date: Tue, 1-Sep-87 18:04:13 EDT Article-I.D.: mitisft.233 Posted: Tue Sep 1 18:04:13 1987 Date-Received: Thu, 3-Sep-87 02:32:33 EDT References: <8708311459.AA25432@oswego> Distribution: world Organization: Convergent Technologies, San Jose, CA Lines: 20 in article <8708311459.AA25432@oswego>, beadel@oswego.UUCP (Edward F. Beadel, Jr.) says: > Does anybody know of a 4.3( or 4.2)bsd version that has been hacked > to allow dialup use? We are having "campus political problems" getting a We have had such a system running internally here at Convergent Technologies for about a year. In that time, it has run under both 4.2 and 4.3 based CTIX (Convergent's UNIX), and will soon be released with our System V.3.1 Streams / 4.3 BSD (with RFS & NFS) product. If you cannot find a non-commercial source, I can put you in touch with someone here and maybe we can get you one of the earlier mbuf-based versions. However its possible you'd have to buy it, either with hardware from us (or one of our customers) or possibly from Lachman Associates. I intend to post some more detailed experiences/queries regarding address selection and routing in this environment sometime in the near future, when I have more time to work on this project... Andrew Knutsen (408) 435-3623 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709012233.AA02304@okeeffe.Berkeley.EDU] <1987090114333800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Help with broken TCP Message-ID: <8709012233.AA02304@okeeffe.Berkeley.EDU> Date: Tue, 1-Sep-87 18:33:38 EDT Article-I.D.: okeeffe.8709012233.AA02304 Posted: Tue Sep 1 18:33:38 1987 Date-Received: Thu, 3-Sep-87 01:49:52 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Right you are! I knew that we had such a problem at one time, but didn't think it had made it out of Berkeley. Your fix is fine; our current version does: if (flags & TH_FIN && tp->t_flags & TF_SENTFIN && tp->snd_nxt == tp->snd_max) tp->snd_nxt--; which should be equivalent. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [273@celerity.UUCP] <1987090114553900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@celerity.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: SUN 3.4 problems Message-ID: <273@celerity.UUCP> Date: Tue, 1-Sep-87 18:55:39 EDT Article-I.D.: celerity.273 Posted: Tue Sep 1 18:55:39 1987 Date-Received: Thu, 3-Sep-87 06:40:47 EDT References: <8708290110.AA13873@ucbvax.Berkeley.EDU> Reply-To: ron@celerity.UUCP (Ron McDaniels) Organization: /usr/lib/news/organization Lines: 25 In article <8708290110.AA13873@ucbvax.Berkeley.EDU> "Jerry Scott" writes: >I think your problem has to do with ICMP Mask Requests from your Sun 3.4. >In release 3.3 and 3.4, diskless suns starting asking the net for >network masks. This is all well and good, but when you have hosts >on your net giving you the wrong answer... . . . > >Hope this helps, I think this was discussed earlier but your message >shows the symptom from the sun's point of view. I hope Sun support >is taking note of this. > >Jerry Scott > >------ Not really Sun's problem. The M68000 family uses net order already. R. L. (Ron) McDaniels CELERITY COMPUTING . 9692 Via Excelencia Way . San Diego, California . 92126 (619) 271-9940 . {decvax || ucbvax || ihnp4 || philabs}!sdcsvax!celerity!ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090119451300> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Tue 1 Sep 87 15:14:06-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA00157; Tue, 1 Sep 87 14:51:48 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: 1 Sep 87 19:45:13 GMT From: barnett@im4u.utexas.edu (Lewis Barnett @ home on the range) Organization: U. Texas CS Dept., Austin, Texas Subject: Need 3Com 3C300 UE interface Message-Id: <2120@im4u.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa I have a somewhat unusual and rather urgent request to make. I need to find a 3Com 3C300 UE (Unibus Ethernet) interface. This was, I believe, 3Com's first Ethernet interface, and has the unusual feature of handling the collision backoff in software. This made it something of a CPU hog, but it is also uniquely suited for experimenting with data link level protocols -- which is what I'm doing. I work with a testbed of four machines with these interfaces, but I have recently discovered that one of our interfaces is a pre-release version with slightly different firmware. The difference causes the older board to dominate the ether at high loads when it resides on a network with the newer boards. This skews performance results. Therefore, I need to replace this board with one matching the hardware revision level of the other three boards. The details: the pre-release board is revision PCB 267-01 Rev. E 21.4; I need a board of revision level PWA 268-01 Rev. A or later. I understand that pre-release revision PCB 267-01 Rev. E 21.7 is identical to this revision, so I'd settle for that. I would need to board for a maximum of six months. I am willing to trade the early revision board in the meantime. It works fine under normal network loads (anything under about 150% offered load) and does significantly better than a "normal" board in higher loads. The firmware change: Ethernet spec says that when attempting to transmit, an interface checks carrier sense, and if it is clear, waits 9.6 usec. then transmits, regardless of the state of carrier sense. The earlier board checks carrier sense *again* after waiting and before initiating transmission. This means that when it is stuck in an environment with boards that follow spec., it avoids a lot of collisions that the other don't. If you have any of these boards and would be willing to do a temporary trade, or know of anyone who might, please contact me by email or phone [(512) 471-9708] as quickly as possible. Lewis Barnett,CS Dept, Taylor Hall 2.124, Univ. of Texas, Austin, TX 78712 -- barnett@im4u.UTEXAS.EDU, barnett@im4u.UUCP, {ihnp4,harvard,seismo,gatech,ctvax}!im4u!barnett ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709020456.AA22471@sccgate.scc.com] <1987090120565100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: enger@sccgate.scc.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: RE Need old 3Com unibus/ethernet adapter Message-ID: <8709020456.AA22471@sccgate.scc.com> Date: Wed, 2-Sep-87 00:56:51 EDT Article-I.D.: sccgate.8709020456.AA22471 Posted: Wed Sep 2 00:56:51 1987 Date-Received: Thu, 3-Sep-87 06:16:56 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 If the firmware on the board is the only difference, why not pull the prom from a "good" board, and burn a copy. Perhaps 3Com would be willing to help? At least they should be able to tell you for sure that firmware IS or IS NOT the only difference. (and maybe they'll be willing to mail you a couple of the old proms, or cut some new ones for you, if you lend them one of the "good" boards. This may be some what idealistic, but it should be good business for the manufacturers to support their customers; perhaps especially researchers. I hope 3Com (or a competitor perhaps) comes forward to help you out. Sorry I can't, Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [84@winfree.UUCP] <1987090206091400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bdale@winfree.UUCP (Bdale Garbee) Newsgroups: rec.ham-radio.packet,comp.os.minix,comp.protocols.tcp-ip Subject: New release of KA9Q Internet Package Message-ID: <84@winfree.UUCP> Date: Wed, 2-Sep-87 10:09:14 EDT Article-I.D.: winfree.84 Posted: Wed Sep 2 10:09:14 1987 Date-Received: Sat, 5-Sep-87 10:50:24 EDT Reply-To: bdale@winfree.UUCP (Bdale Garbee) Organization: Bdale's Berkeley Box, Colorado Springs Lines: 179 Announcing an update to the KA9Q TCP/IP software package release of 870526.0, bringing the current release date up to 870829.0. This update adds fixes bugs, and adds some minor functionality. A new release will occur in a couple of weeks with support for 4bsd and sysV unix machines, this version still supports only the PC and PC clone class of machines. The changes: - Improved KISS bits for the TNC1 from Gerard, PA0GRI. - the ASCII text at the top of one of the TNC2 hex files is gone now. - Minor tweaks to BM from Gerard, PA0GRI, Phil KA9Q, and yours truly. Biggest noticeable differences are that BM no longer looks at the hosts.net file at all, but instead passes symbolic hostnames to the smtp client in net... and we once again changed the text entry code. It's more like bsd Mail now. Default is a silly text entry routine, a "~e" gets you into your favorite editor, and a "~p" shows what you've typed so far. - NET.EXE understanding of symbolic hostnames ala the hosts.net file has been extended. You now need to wrap numeric IP addresses in square brackets, as in "[44.32.0.16]", as you can use symbolic names anywhere you need to use an IP address (including in the autoexec.net file!) - Since BM no longer deals with IP addresses, a "gateway" command has been added to NET.EXE, so that it knows where to send mail that fails the lookup in hosts.net. - Internal changes and a fix to the ftp server so that it now handles NLST command properly, all from Phil, KA9Q. Bugs that were in the 870526.5 interim release that was only distributed in a limited fashion apparently disappeared with the latest tweaks... - documentation has (as usual) been updated somewhat. - some other random tweaks I'm sure I've forgotten... What to do once you have software, aka "getting an IP address": Users of this software package become part of the "global IP internet", and as such need to obtain unique IP address assignments for each host they plan to put on the air, or "on the wire". Major metropolitan areas in the US, and countries with active TCP-using groups probably already have blocks of addresses in amateur radio 44.X.X.X block assigned to them. Ask around locally before you go any further. If there is no local address block in your area, and/or noone is coordinating address assignments for your local net, contact Wally Linstruth WA6JPR. Wally is the global top-level address administrator for the ham radio 44.X.X.X subnet. Wally may be reached by email at wally%net1.ucsd.edu@sdcsvax.ucsd.edu or wally@net1.ucsd.edu or ...!sdcsvax!net1!wally or via the new forwarding mechanism I have set up for those sites who know how to reply via mail to this message, but can't reach Wally's machine directly: winfree!wally -or- wally@winfree.uucp or wally%winfree.uucp@flash.bellcore.com How to obtain the KA9Q Internet software: - Via uucp, the files are on winfree in tar archives as: /usr/spool/uucppublic/pub/ka9q_all.tar.Z 16 bit Compress 4.0 /usr/spool/uucppublic/pub/ka9q_all.t12.Z 12 bit Compress 4.0 For Anonymous UUCP login, use phone number 303/593-0696, at 2400 baud (it will do 1200 if you send a return to rotate it down), "standard Unix login sequence", username of "Uanon", password of "notFTP". An example L.sys entry ala winfree's uucp would be: winfree Any ACU 2400 13035930696 ogin: Uanon word: notFTP I've never run an anonymous login for uucp before, so let me know if I got it wrong! A reasonable command to issue to pick up the 12-bit distribution would be uucp winfree!~/pub/ka9q_all.t12.Z /usr/spool/uucppublic - ***** My BBS is currently down with a dead hard drive. If anyone ***** has a spare drive they would be willing to donate to the cause, ***** *please* get in touch with me ASAP! Cashflow around here is ***** a joke... :-( Normally, Via Opus, log in to my BBS and download from the appropriate files area. There are several .ARC files for the full distribution, one for each of the directories. SeaDog file requests are ok. I have configured my BBS to allow first time users ample resources to download the full distribtuion at 1200 baud. The phone number is 303/593-0766. If you have any trouble downloading from the BBS, please let me know. Speeds that are supported include 300, 1200, and 2400. - Via US Snail, Andy Freeborn N0CCZ has agreed to make floppy copies. To get a copy from him, send $5 AND a completed return address mailing label (orders without a mailing label will be considered contributions to the BBS hard drive fund, see above... :-) to: Andy Freeborn, N0CCZ 5222 Borrego Drive Colorado Springs, CO 80918 USA What you get for the $5: 5 floppies, including two of RFC's and IEN's that relate to the code, two that include the actual release, and one that is intended to be a sort of "plug and play" disk for getting on the air immediately... For those who just want the RFC/IEN disks, Andy will send you just those two disks for $2 and a mailing label. If you want any particular RFC or IEN, contact Andy to find out what archive it is in (we have them all packed up, one ARC per 360k pc disk), and he will send you that RFC or IEN, along with many others, on a floppy for $1/disk. You can't mix and match, you get the block of documents that are in a given archive. DO NOT SEND floppies, mailers, postage, etc... but DO send the mailing label! Andy is also reachable as winfree!andy or andy%winfree.uucp@bellcore.com if you need more information (?). Andy is within an on-air FTP of me, so we should be able to keep his bits up to date! - on the ARPAnet, or attached portions of the Internet, look on louie.udel.edu via anonymous FTP for the files in the directory pub/ka9q - Within a day or two of a new release, the code should also be available from the following additional secondary distribution points: from Doug KD4NC in Atlanta, GA uucp: winfree!kd4nc!dug from Bob Hoffman N3CVL in Pittsburgh, PA arpa: rbh@cadre.dsl.pittsburgh.edu uucp: pitt!hoffman from Wally Linstrugh WA6JPR in Santa Barbara, CA arpa: wally@net1.ucsd.edu from Brian Kantor at UCSD. (via anonymous FTP?) arpa: tcp-group-request@sdcsvax.ucsd.edu uucp: sdcsvax!tcp-group-request Unreleased (read: under development) versions are often available on louie.udel.edu, generally alongside official releases... caveat emptor... If anyone has any trouble getting hold of a copy of the code, please let me know! How to contact me: Bdale Garbee, N3EUA 1433 Territory Trail Colorado Springs, CO 80919 303/590-2868w, 303/593-9828h *** go easy on the phone calls please, I'm not getting much sleep! *** uucp: {bellcore,crash,hp-lsd,ncc,pitt,vixie}!winfree!bdale arpa: bdale%winfree.uucp@flash.bellcore.com bdale@net1.ucsd.edu fido: Bdale Garbee at 128/19, 303/593-0766, 300/1200/2400 baud, 24hrs (*DOWN*) packet: n3eua @ k0hoa -- Bdale Garbee, N3EUA phone: 303/593-9828 h, 303/590-2868 w uucp: {bellcore,crash,hp-lsd,ncc,pitt,usafa,vixie}!winfree!bdale arpa: bdale%winfree.uucp@bellcore.com fido: sysop of 128/19 packet: n3eua @ k0hoa, Colorado Springs ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709021539.AA22092@opal.berkeley.edu] <1987090207394700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: minshall@OPAL.BERKELEY.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Are simultaneous TCP opens useful? Message-ID: <8709021539.AA22092@opal.berkeley.edu> Date: Wed, 2-Sep-87 11:39:47 EDT Article-I.D.: opal.8709021539.AA22092 Posted: Wed Sep 2 11:39:47 1987 Date-Received: Sat, 5-Sep-87 06:14:53 EDT References: <1261@spice.cs.cmu.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Eric, Whether "simultaneous" opens will always succeed or randomly fail depends on how the underlying TCP service is implemented. If the user code needs to look like this: { if (connect() == FAIL) { listen(); } } then there is a race condition in which both sides may hang in listen(). Side A fails to connect, but before A issues listen, side B tries to connect and fails. However, if the underlying TCP service allows this: { connect_or_listen(); } as a primitive, then the simultaneous case seems to me to be guaranteed to win. Note that I don't know of any underlying services that allow the second form. Greg Minshall ----MESSAGE-END---- ----MESSAGE-BEGIN---- [658@phoenix.PRINCETON.EDU] <1987090208312800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: asjoshi@phoenix.PRINCETON.EDU (Amit S. Joshi) Newsgroups: comp.protocols.tcp-ip,comp.sources.wanted,comp.sys.ibm.pc Subject: Wanted: TCP/IP for an IBM PC/AT Message-ID: <658@phoenix.PRINCETON.EDU> Date: Wed, 2-Sep-87 12:31:28 EDT Article-I.D.: phoenix.658 Posted: Wed Sep 2 12:31:28 1987 Date-Received: Sat, 5-Sep-87 06:58:20 EDT Reply-To: asjoshi@phoenix.UUCP (Amit S. Joshi) Distribution: na Organization: Princeton Univ. Computing and Information Technology Lines: 27 Keywords: TCP/IP, IBM PC/AT, Sockets Hi, As a part of a simulator being built here I have to connect up an Iris (running UNIX) and an IBM PC/AT running DOS 3.2. I thought of using a serial link but it turns out to be too slow. The Iris does not have a parallel port (and to get an optional one costs around $4k I'm told). The IBM PC/AT has got a 3-Com board and has the MIT TCP/IP package. The Iris also has a complete TCP/IP package. I want to use this to hook up the Iris and the AT. Now the Iris has Socket libraries which simplify opening ports from programs. I was looking for something similar at the AT end of the business. I DON'T have the source to the MIT package but the binaries definitely do not come with a socket library (or its equivalent). Anybody know of anything out there? Preferably Public Domain, if not at a reasonable cost. Also preference is for sources. There is a restriction : I have only Lattice C v3 and Turbo C v1 compilers so binary libraries should be compatible with these compilers. Thanks. -- Amit Joshi | BITNET : Q3696@PUCC.BITNET | USENET : ...seismo!princeton!phoenix!asjoshi "There's a pleasure in being mad ...which none but madmen know!" St.Dryden ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090209280000> Return-Path: Received: from miasma.Stanford.EDU ([36.22.0.152]) by SRI-NIC.ARPA with TCP; Wed 2 Sep 87 16:23:50-PDT Received: by miasma.Stanford.EDU; Wed, 2 Sep 87 16:28:37 PDT Date: 2 Sep 1987 1628-PDT (Wednesday) From: Glenn Trewitt To: tcp-ip@sri-nic.arpa Cc: Glenn Trewitt Subject: Research on large packet-switched network behavior I am trying to find out about people who are doing or have done research related to my own. Read on if you think you might have some pointers... When not working in the various network management activities, I am supposed to be writing a thesis describing the results of my studies of the Stanford Ethernet's behavior and performance. The particular areas that I am interested in are: micro-level behavior of networks/links interarrival times packet size distribution traffic volume behavior of routers (gateways) packet delay congestion macro-level behavior of the whole internetwork traffic matrices conclusions from this data suitablility of the topology for the presented load saturation point for routers performance as load increases performance as size/complexity increases Yes, I realize that this is a lot of stuff, and I don't expect to actually cover it all, but it's a starting point. What I am interested in finding out from the people on this list is to see if there has been published research on these topics based upon Internet experience. I realize that many of these parameters (such as saturation point:-) have been determined by actual experiment in the Arpanet, but has anyone actually written about it. [I suspect that people may be too busy fending off the aligators to actually write reports, but I can hope.] Thanks in advance, Glenn Trewitt If you can't reply to miasma.Stanford.EDU, try amadeus.Stanford.EDU or shasta.Stanford.EDU. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090210562100> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Thu 3 Sep 87 09:14:45-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA13545; Thu, 3 Sep 87 08:56:01 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: 2 Sep 87 10:56:21 GMT From: bpa!sjuvax!bbanerje@burdvax.prc.unisys.com (B. Banerjee) Organization: St. Joseph's University, Phila. PA. Subject: Replies to "Rarp under 4.3 BSD" Message-Id: <846@sjuvax.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa Hi, Some time ago, I posted an article enquiring as to the availability of RARP under 4.3 BSD to this newsgroup. Several people were kind enough to respond. In the event that you were waiting with bated breath (unlikely!), here's what I learned. a. 4.3 BSD doesn't support RARP, in any way shape or form. b. Sun Unix 3.x ( Lim x->4) does support RARP. In order to turn this on, you have to fiddle with /etc/ethers, reconfigure the kernel to include the NIT code , and start an rarpd from rc.local. c. Rarp can be added to 4.3 BSD. Now, as the prospect of writing a rarp daemon doesn't excite me, I'm going to go with the path of least resistance -- running it on the Sun. If, on the other hand, you are in a similar dilemna without recourse to a Sun; all is not lost. You can write a rarp daemon with the aid of the 'enet' ethernet packet filter software that was part of the ``user contributed software '' that came with 4.3 BSD. This essentially gives you access to ethernet packets that haven't been snarfed up by IP or ICMP in the kernel. You can then handle the 'rarp' packets yourself. I personally believe that it makes the most sense to place the rarp handling stuff along with the 'arp' handling stuff in the kernel (netinet/if_ether.c). Consider the following facts: i) The internet-address to ethernet-address mappings already exist in the kernel. ii) Proxy arp is supported. Now suppose that a RARP packet is received. The code could check it's tables to see if it was a 'published' entry, performing the rarp service if it was. The table could be updated via 'arp -s' as with proxy arp. If you want to write a RARP daemon, but don't know where to start; I recommend Doug Comer's excellent book "Internetworking with Xinu". He has some code in there that you could almost steal verbatim. I would like to thank the following people for taking the time to respond to my query; and answering questions or giving me pointers on where to look. bzs@bu-cs.bu.edu (Barry Shein) karels%okeeffe@berkeley.edu (Mike Karels) raj@purdue.edu (Raju Yavatkar) sun!guy (Guy Harris) milazzo@rice.edu (Paul Milazzo) emory!tony (Tony Vincent) matt@oddjob.uchicago.edu (Matt Crawford) narten@purdue.edu (Thomas Narten) sdcsvax!brian (Brian Kantor) If you sent me mail and I haven't mentioned your name -- my apologies. The first few letters were read, replied to and then deleted before I realized that I would receive so many replies. Thanks again to anyone who helped with this one. Regards, Binayak Banerjee {allegra | astrovax | bpa | burdvax}!sjuvax!bbanerje bbanerje%sjuvax.sju.edu@relay.cs.net ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709022106.AA16267@noao.arizona.edu] <1987090213060500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: grandi@NOAO.ARIZONA.EDU (Steve Grandi) Newsgroups: comp.protocols.tcp-ip Subject: A routing mystery Message-ID: <8709022106.AA16267@noao.arizona.edu> Date: Wed, 2-Sep-87 17:06:05 EDT Article-I.D.: noao.8709022106.AA16267 Posted: Wed Sep 2 17:06:05 1987 Date-Received: Sat, 5-Sep-87 07:19:28 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 34 I have a mystery I don't understand; perhaps someone out there with more knowledge can enlighten me. My building Ethernet is network 192.31.165 (noao-tucson). One VAX 11/750, noao.arizona.edu, running 4.3BSD serves as gateway between my net and the University of Arizona net (univ-ariz, 128.196). A gateway machine on univ-ariz, jvax.ccit.arizona.edu is linked to the Princeton Supercomputer center (jvnc-net, 128.121.0) where a gateway machine, fuzz.csc.org, connects to the NSFnet. Hosts on noao-tucson have default routes to noao.arizona.edu which has a default route to jvax.ccit.arizona.edu which has a default route to fuzz.csc.org. noao.arizona.edu serves as a central TCP/IP mail machine for our facility; thus I spend a lot of time watching mail queues. What I see is an almost total inability to communicate to wiscvm.wisc.edu, the Bitnet mail gateway (at least for a couple more months). Since the other astronomers here beat on me to get the Bitnet mail flowing, I've been poking around and have discovered the mystery. From noao.arizona.edu (128.196.4.1 and 192.31.165.2), pings and telnet attempts to wiscvm.wisc.edu fail. Yet, simultaneously, pings and telnet connections from aquila.noao.arizona.edu (192.31.165.6) to wiscvm work fine, even though the packets from aquila have to go through noao.arizona.edu to reach wiscvm! Similar attempts from jvax.ccit.arizona.edu to contact wiscvm also fail. The only explanation I can come up with is that there is bad routing information somewhere in the Internet for net 128.196, but good routing information for net 192.31.165. How can I investigate this possibility? Or am I missing something obvious? Steve Grandi, National Optical Astronomy Observatories, Tucson AZ, 602-325-9228 UUCP: {arizona,decvax,hao,ihnp4}!noao!grandi or uunet!noao.arizona.edu!grandi Internet: grandi@noao.arizona.edu SPAN/HEPNET: 5356::GRANDI or DRACO::GRANDI ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709022110.AA29315@ACC-SB-UNIX.ARPA] <1987090213104400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kzm@ACC-SB-UNIX.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Are simultaneous TCP opens useful? Message-ID: <8709022110.AA29315@ACC-SB-UNIX.ARPA> Date: Wed, 2-Sep-87 17:10:44 EDT Article-I.D.: ACC-SB-U.8709022110.AA29315 Posted: Wed Sep 2 17:10:44 1987 Date-Received: Fri, 4-Sep-87 03:16:56 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 15 As Art Berggreen said in an earlier message, ACC has a product called SIMON which provides a TCP-based service for peer subscribers (as opposed to the more common Client/Server model). Several years ago when we were implementing this, we needed a scheme which avoided the race condition which Greg Minshall pointed out. So, we asked Jon Postel about the validity of using the primitive which Greg calls "connect_or_listen", which we call a "symmetric" (as opposed to passive or active) open. Jon said if we wanted to enhance our ULP interface like this, then fine. This single primitive requests an active open with an "automatic" fallback to passive if the active fails. When both subscribers use this primitive, the ability to fallback immediately eliminates the race condition. Keith. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709030242.AA00186@ucbvax.Berkeley.EDU] <1987090215280000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: trewitt@MIASMA.STANFORD.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Research on large packet-switched network behavior Message-ID: <8709030242.AA00186@ucbvax.Berkeley.EDU> Date: Wed, 2-Sep-87 19:28:00 EDT Article-I.D.: ucbvax.8709030242.AA00186 Posted: Wed Sep 2 19:28:00 1987 Date-Received: Sat, 5-Sep-87 02:43:32 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 44 I am trying to find out about people who are doing or have done research related to my own. Read on if you think you might have some pointers... When not working in the various network management activities, I am supposed to be writing a thesis describing the results of my studies of the Stanford Ethernet's behavior and performance. The particular areas that I am interested in are: micro-level behavior of networks/links interarrival times packet size distribution traffic volume behavior of routers (gateways) packet delay congestion macro-level behavior of the whole internetwork traffic matrices conclusions from this data suitablility of the topology for the presented load saturation point for routers performance as load increases performance as size/complexity increases Yes, I realize that this is a lot of stuff, and I don't expect to actually cover it all, but it's a starting point. What I am interested in finding out from the people on this list is to see if there has been published research on these topics based upon Internet experience. I realize that many of these parameters (such as saturation point:-) have been determined by actual experiment in the Arpanet, but has anyone actually written about it. [I suspect that people may be too busy fending off the aligators to actually write reports, but I can hope.] Thanks in advance, Glenn Trewitt If you can't reply to miasma.Stanford.EDU, try amadeus.Stanford.EDU or shasta.Stanford.EDU. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709022201.aa29771@Huey.UDEL.EDU] <1987090218011900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: IP assigned protocol numbers Message-ID: <8709022201.aa29771@Huey.UDEL.EDU> Date: Wed, 2-Sep-87 22:01:19 EDT Article-I.D.: Huey.8709022201.aa29771 Posted: Wed Sep 2 22:01:19 1987 Date-Received: Sat, 5-Sep-87 07:45:31 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Kurt, GGP is used only by the LSI-11 core gateways, who would be sore vexed, indeed, if some host tried to horn in that protocol. Don't worry about the number (it really is 3), just destroy all references to it, wherever found. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090220000000> Received: from bluto.scc.com by SRI-NIC.ARPA with TCP; Wed 2 Sep 87 22:07:31-PDT Date: 3 Sep 87 01:00:00 EST From: "GBURG::ENGER" Subject: RE A routing mystery -- some small input To: "grandi" cc: tcp-ip@sri-nic.arpa,enger Reply-To: "GBURG::ENGER" Being curious, I did some pinging from my direct net-10 host, SCCGATE.SCC.COM (10.11.0.20). It has its DEFAULT route set to PURDUE-CS-GW.ARPA. I ping successfully off of FUZZ.CSC.ORG (128.121.50.20) JVAX.CCIT.ARIZONA.EDU (128.121.50.100) JVAX.CCIT.ARIZONA.EDU (128.196.1.1) NOAO.ARIZONA.EDU (128.196.4.1) I could not raise a response from NOAO.ARIZONA.EDU (192.31.165.2) for quite some time. I made a number of attempts over a 10-15 minute period. I found this curious, as this is simply the address on the 192.31.165 network for the machine I had just heard from using the 128.196 network. Further, I had initially been unable to raise any hosts on 192.31.165, and after I started to hear from the 192.31.165 side of NOAO.ARIZONA.EDU, I also found that I could reach those back hosts, but the ping echo times were much longer than those obtained from the 128 addressed gateways/hosts. I checked my routing table. Here is what I found. destination net gateway 128.121.0 psc.psc.edu 128.196.0 psc.psc.edu 192.31.165 DCEC-MILNET-GW.ARPA It appears that I'm routing through a MILNET gateway to reach net 192.31.165. Hope this info can be of some help to you, Bob ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709030513.AA02698@ucbvax.Berkeley.EDU] <1987090222000000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: enger%gburg.DECnet@BLUTO.SCC.COM ("GBURG::ENGER") Newsgroups: comp.protocols.tcp-ip Subject: RE A routing mystery -- some small input Message-ID: <8709030513.AA02698@ucbvax.Berkeley.EDU> Date: Thu, 3-Sep-87 02:00:00 EDT Article-I.D.: ucbvax.8709030513.AA02698 Posted: Thu Sep 3 02:00:00 1987 Date-Received: Sat, 5-Sep-87 08:29:46 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "GBURG::ENGER" Organization: The ARPA Internet Lines: 33 Being curious, I did some pinging from my direct net-10 host, SCCGATE.SCC.COM (10.11.0.20). It has its DEFAULT route set to PURDUE-CS-GW.ARPA. I ping successfully off of FUZZ.CSC.ORG (128.121.50.20) JVAX.CCIT.ARIZONA.EDU (128.121.50.100) JVAX.CCIT.ARIZONA.EDU (128.196.1.1) NOAO.ARIZONA.EDU (128.196.4.1) I could not raise a response from NOAO.ARIZONA.EDU (192.31.165.2) for quite some time. I made a number of attempts over a 10-15 minute period. I found this curious, as this is simply the address on the 192.31.165 network for the machine I had just heard from using the 128.196 network. Further, I had initially been unable to raise any hosts on 192.31.165, and after I started to hear from the 192.31.165 side of NOAO.ARIZONA.EDU, I also found that I could reach those back hosts, but the ping echo times were much longer than those obtained from the 128 addressed gateways/hosts. I checked my routing table. Here is what I found. destination net gateway 128.121.0 psc.psc.edu 128.196.0 psc.psc.edu 192.31.165 DCEC-MILNET-GW.ARPA It appears that I'm routing through a MILNET gateway to reach net 192.31.165. Hope this info can be of some help to you, Bob ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090223285400> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Thu 3 Sep 87 02:37:50-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA06594; Thu, 3 Sep 87 02:16:15 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: 2 Sep 87 23:28:54 GMT From: gatech!mcdchg!usenet@hplabs.hp.com (Yvonne Sun) Organization: University of California, Davis Subject: "select" problem Message-Id: <1588@mcdchg.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa Systems: 4.3 BSD UNIX, ULTRIX 1.2, Sun UNIX 4.2 Machines: VAX 750, VAX 8600, Sun 2 I have a problem in my program. In one of the routines, I use "select" on several opened sockets inside a for loop. One of the sockets(call it S) is a passive one, i.e. it is there to accept connections from other sockets. If S is selected, an "accept" will be executed, trying to accept the connection. Since "select" is used, S should be selected only when there is a pending connection request. My problem is that, after the program is executed for a while, socket S is always selected and the accept call will return unsuccessfully with the error code being 60( i.e. ETIMEOUT). After that, S will be selected again and again and accept will fail every time it is called. What troubles me is that S is selected even I haven't tried to connect to it. I am sure that I reset the input mask used in the select everytime right before select is called. Have you seen something like that before? Or do you have any idea about what causes this phenomenon? I would appreciate any opinion and suggestions. Yvonne Sun at UC Davis address: sun@iris.ucdavis.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709031718.AA02339@utkcsunix.CS.UTK.EDU] <1987090309182100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: moore@UTKCS2.CS.UTK.EDU (Keith Moore) Newsgroups: comp.protocols.tcp-ip Subject: request for mailer information Message-ID: <8709031718.AA02339@utkcsunix.CS.UTK.EDU> Date: Thu, 3-Sep-87 13:18:21 EDT Article-I.D.: utkcsuni.8709031718.AA02339 Posted: Thu Sep 3 13:18:21 1987 Date-Received: Sat, 5-Sep-87 11:32:37 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 [Apologies if this isn't strictly within the scope of this group] I'm looking for a better mailer! I'm tired of using the mail programs supplied with VMS and Berkeley Unix (Ultrix 1.2). I'd like something that can keep track of large numbers of old messages, with database-like searching and query capabilities. It would also be nice if it would keep messages in order, remember which messages have been replied to, follow message chains, etc. And I'm sure a sophisticated mailer would have other useful features I haven't dreamed about. So I'm soliciting information on alternative mail management programs for both VMS and Unix systems. I'm especially interested in anything that's cheap or free, and easily available. Please respond by mailing directly to me. If someone wants the results, send me mail and I'll send a summary. Keith Moore Internet: moore@utkcs2.cs.utk.edu UT Computer Science Dept. CSnet: moore@tennessee Knoxville Tennessee BITNET: moore@utkcs1 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709032103.AA26339@columbia-pdn] <1987090313034800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cam@columbia-pdn (Chris Markle acc_gnsc) Newsgroups: comp.protocols.tcp-ip Subject: Multiple 331 password responses in FTP protocol Message-ID: <8709032103.AA26339@columbia-pdn> Date: Thu, 3-Sep-87 17:03:48 EDT Article-I.D.: columbia.8709032103.AA26339 Posted: Thu Sep 3 17:03:48 1987 Date-Received: Sat, 5-Sep-87 12:08:00 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 83 Folks, ACC distributes an MVS implementation of the Internet protocol suite called ACCES/MVS. We are in the process of adding support to interface ACCES to various MVS security packages using the MVS-provided SAF (Security Authorization Facility) interface. SAF allows an application subsystem to use a common interface to the access control facility, be that RACF, ACF2, Top Secret or Alert/MVS (and possibly others). One problem has emerged that I want to present to this group for comments and/or suggestions. Systems like RACF will expire a user's password after a certain period of time; this is quite commonly used at the average MVS site. We coded the changes in the FTP server to detect this (after USER and PASS FTP commands have been issued) and if the password is expired to prompt the Client FTP for a new (second) password. If the Client is 4.3 BSD, it assumes that the second password prompt (331 response) is really a 332 response, prompts the user for an account, and sends an ACCT FTP command in response to our 331 password prompt. It looks something like this: ACCES/MVS UNIX 220 service ready ---> <--- USER chris 331 ok; need password ---> <--- PASS chris_pswd (obtained with Client FTP password prompt) 331 expired; need new password ---> At this point, 4.3 BSD prompts the Unix FTP user for an account and if one is entered in, sends it in an FTP ACCT command. Obviously the 4.3 FTP client is not vigorously checking the reply code; the "need acct" reply code is 332 not 331. By the way, if you send the USER, PASS, and 2nd PASS with the QUOTE command, everything works properly. Now before you tell me to look at the state diagrams in the FTP spec (which show a transition to the ACCT state after receipt of a 3xx response to the PASS command) let me point out that the spec section with state diagrams states: "Here we present state diagrams for a VERY SIMPLE MINDED FTP implementation. Only the FIRST DIGIT of the reply codes is used" (Capitalization is mine) This suggests to me that the spec does not say "implement your FTP using these simple-minded state diagrams" but "here are SAMPLE state diagrams to help you understand the FTP protocol". So --- a couple of questions for you folks to ponder (and hopefully to respond to): 1) Our position is that if the FTP server sends more than one 331 response in a row, this is legitimate and Client FTP implementations should properly handle this. Do you wise folks agree? 2) If you don't agree, what brilliant ideas can you give us on how to do this? (Please don't say that we should accept the ACCT info following the 1st PASS as the 2nd PASS!?!) Please respond to me or to this group; I will summarize at the end. Thanks in advance for your advice in this matter. Chris Markle - cam@acc-sb-unix.arpa - (301)290-8100 PS - Do not try to respond to me at acc-md-unix.arpa; use acc-sb-unix.arpa which will forward to me at acc-md-unix PS - I know this isn't very exciting stuff but it is a real problem that will affect real users at real sites. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1667@briar.Philips.Com] <1987090313171800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jmr@philabs.Philips.Com (Joanne Mannarino) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: There is a solution to my SUN 3.4 problem Message-ID: <1667@briar.Philips.Com> Date: Thu, 3-Sep-87 17:17:18 EDT Article-I.D.: briar.1667 Posted: Thu Sep 3 17:17:18 1987 Date-Received: Sat, 5-Sep-87 16:48:54 EDT Organization: Philips Laboratories, Briarcliff Manor, NY. Lines: 28 Thanks for all your responses to my 3.4 problem. We have finally found a solution. The 3.4 release introduced subnetting. The way the networking software for 3.4 works is that the diskless client comes up and requests a subnet mask. It waits for a response from the server. The TCP/IP software (we're running XLAN but problems have occured with Wollongong also) responds with a subnet mask that is invalid. The diskless client is supposed to check it, determine that it is invalid, disregard it, and wait for the server to respond with the correct subnet mask. BUT with the 3.4 release, the client wasn't ignoring the invalid subnet mask so thus it would hang. SUN has provided a patch to the kernel software to take care of this. If anyone else is still having this problem, you should call SUN support and ask for the fix to bug id 1006127. This solution was sent to me by Bill Nowicki, Network Software Developer at SUN. According to him, they have a guard against this in the 3.5 release. -Joanne Mannarino -- joanne mannarino uunet!philabs!jmr philips laboratories or (914)945-6008 jmr@philabs.philips.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1669@briar.Philips.Com] <1987090313211900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jmr@philabs.Philips.Com (Joanne Mannarino) Newsgroups: comp.protocols.tcp-ip Subject: There is a solution to my SUN 3.4 problem Message-ID: <1669@briar.Philips.Com> Date: Thu, 3-Sep-87 17:21:19 EDT Article-I.D.: briar.1669 Posted: Thu Sep 3 17:21:19 1987 Date-Received: Sat, 5-Sep-87 16:49:07 EDT Organization: Philips Laboratories, Briarcliff Manor, NY. Lines: 27 Thanks for all your responses to my 3.4 problem. We have finally found a solution. The 3.4 release introduced subnetting. The way the networking software for 3.4 works is that the diskless client comes up and requests a subnet mask. It waits for a response from the server. The TCP/IP software (we're running XLAN but problems have occured with Wollongong also) responds with a subnet mask that is invalid. The diskless client is supposed to check it, determine that it is invalid, disregard it, and wait for the server to respond with the correct subnet mask. BUT with the 3.4 release, the client wasn't ignoring the invalid subnet mask so thus it would hang. SUN has provided a patch to the kernel software to take care of this. If anyone else is still having this problem, you should call SUN support and ask for the fix to bug id 1006127. This solution was sent to me by Bill Nowicki, Network Software Developer at SUN. According to him, there will be a guard against this in the 3.5 release. -Joanne Mannarino -- joanne mannarino uunet!philabs!jmr philips laboratories or (914)945-6008 jmr@philabs.philips.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12331754458.6.SATZ@MATHOM.CISCO.COM] <1987090313502500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: SATZ@MATHOM.CISCO.COM (Greg Satz) Newsgroups: comp.protocols.tcp-ip Subject: Re: Replies to "Rarp under 4.3 BSD" Message-ID: <12331754458.6.SATZ@MATHOM.CISCO.COM> Date: Thu, 3-Sep-87 17:50:25 EDT Article-I.D.: MATHOM.12331754458.6.SATZ Posted: Thu Sep 3 17:50:25 1987 Date-Received: Sat, 5-Sep-87 16:39:46 EDT References: <846@sjuvax.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 A rarp daemon exists for 4.3BSD using the enet packet filter. It was developed and used extensively at Stanford. The enet device code should just "drop in" to the distributed 4.3BSD system. The only major change would be to the ethernet driver to insert the hooks to pass the packet off to the enet code instead of just pitching it. If you are interested in the daemon, drop me a note and I will give you the name of people within Stanford who may be able to help. Note that I cannot provide code since I am not affiliated with Stanford. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090402384800> Received: from GUNTER-ADAM.ARPA by SRI-NIC.ARPA with TCP; Fri 4 Sep 87 05:41:34-PDT Date: 4 Sep 1987 07:38:48 CDT Subject: Unisys 5000, Unix, and TCP/IP From: AFDDN.TCP-IP@GUNTER-ADAM.ARPA To: tcp-ip@SRI-NIC.ARPA Just a request for any information out there. Does anybody have any experience with internetting Unisys 5000s? These beasts run some flavor of Unix. The words filtering through the grapevine are that Unisys wrote TCP/IP, FTP, SMTP and Telnet from scratch, and that there are a few problems with it. Any comments are welcome. Darrel Beach ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709041300.AA05135@ucbvax.Berkeley.EDU] <1987090404384800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: AFDDN.TCP-IP@GUNTER-ADAM.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Unisys 5000, Unix, and TCP/IP Message-ID: <8709041300.AA05135@ucbvax.Berkeley.EDU> Date: Fri, 4-Sep-87 08:38:48 EDT Article-I.D.: ucbvax.8709041300.AA05135 Posted: Fri Sep 4 08:38:48 1987 Date-Received: Sat, 5-Sep-87 17:28:09 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Just a request for any information out there. Does anybody have any experience with internetting Unisys 5000s? These beasts run some flavor of Unix. The words filtering through the grapevine are that Unisys wrote TCP/IP, FTP, SMTP and Telnet from scratch, and that there are a few problems with it. Any comments are welcome. Darrel Beach ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709041354.AA00736@milk4] <1987090405540000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ejc@SPAM.ISTC.SRI.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: request for mailer information Message-ID: <8709041354.AA00736@milk4> Date: Fri, 4-Sep-87 09:54:00 EDT Article-I.D.: milk4.8709041354.AA00736 Posted: Fri Sep 4 09:54:00 1987 Date-Received: Sat, 5-Sep-87 17:54:25 EDT References: <8709031718.AA02339@utkcsunix.CS.UTK.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Keith- We have been using MH and Gueuemacs as a mail handler on UNIX systems (Vaxen and Suns). The combination has most of the general features you mentioned, although I think there are still holes, especailly when dealing with large volumes of mail. Since both programs originated elsewhere, I am sure you will receive ample descriptions from others. I am interested in the results of your survey, so please send me a summary. Earl Craighill SRI International ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709050153.AA18790@ucbvax.Berkeley.EDU] <1987090408210000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: NS-DDN@DDN3.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: Multiple 311 password responses in FTP protocol Message-ID: <8709050153.AA18790@ucbvax.Berkeley.EDU> Date: Fri, 4-Sep-87 12:21:00 EDT Article-I.D.: ucbvax.8709050153.AA18790 Posted: Fri Sep 4 12:21:00 1987 Date-Received: Sat, 5-Sep-87 22:33:14 EDT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Chris, you err in not carefully reading section 5.4 of RFC959. The table of replies to the PASS command (which must be "strictly adhered to") does NOT include 331. I would suggest you avoid the trap of trying to support the password change function through FTP and generate an appropriate 5xy reply to the PASS command with text from the security package. Best regards, Dave Craig Network Solutions, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090408210001> Received: from ddn3.arpa by SRI-NIC.ARPA with TCP; Fri 4 Sep 87 09:33:46-PDT Date: 4 Sep 87 12:21 EDT From: NS-DDN @ DDN3.arpa Subject: Re: Multiple 311 password responses in FTP protocol To: cam @ acc-sb-unix.arpa CC: tcp-ip @ sri-nic.arpa Chris, you err in not carefully reading section 5.4 of RFC959. The table of replies to the PASS command (which must be "strictly adhered to") does NOT include 331. I would suggest you avoid the trap of trying to support the password change function through FTP and generate an appropriate 5xy reply to the PASS command with text from the security package. Best regards, Dave Craig Network Solutions, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709041634.AA11908@topaz.rutgers.edu] <1987090408342100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Multiple 331 password responses in FTP protocol Message-ID: <8709041634.AA11908@topaz.rutgers.edu> Date: Fri, 4-Sep-87 12:34:21 EDT Article-I.D.: topaz.8709041634.AA11908 Posted: Fri Sep 4 12:34:21 1987 Date-Received: Sat, 5-Sep-87 22:46:00 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 UNIX uses the simple minded approach. Only the first digit is checked. (This is for infomration). I think ACCESS/MVS is doing the wrong thing. The reply strings are supposed to be informative only, the client is supposed to be able to make it's decisions based on the numbers alone. The only defined acceptable replies in the spec are 3XX meaning send account, 2XX Success, and 5XX error. Doing anything else is just asking for trouble. The last two digits are there to provide a finer differentiation of the error, but not to change the flow of control. Beyond that conceptual problem, if I understand what is going on here, you're second password string actually changes the password? This is a horrendous security problem and really ought not to be done in FTP. Better to just return an error (EXPIRED PASSWORD) and leave the user to correct the situation through other channels. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709041644.AA02132@uunet.UU.NET] <1987090408392200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mo@maximo.UUCP (Mike O'Dell) Newsgroups: comp.protocols.tcp-ip Subject: Unisys 5000 Message-ID: <8709041644.AA02132@uunet.UU.NET> Date: Fri, 4-Sep-87 12:39:22 EDT Article-I.D.: uunet.8709041644.AA02132 Posted: Fri Sep 4 12:39:22 1987 Date-Received: Sat, 5-Sep-87 23:11:20 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 I think that is the Arete box remarketed by Unisys. If so, they use an Excelan 201 board for the TCP-IP support. This code is derived from the 4.1a TCP code, but has had some bugs fixed and some features added. As to which ones, however, ask Unisys, Arete, and possibly Excelan. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090411010000> Mail-From: STJOHNS created at 4-Sep-87 18:01:58 Date: 4 Sep 1987 18:01-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: Multiple 331 passwd responses in FTP protocol From: STJOHNS@SRI-NIC.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]Fri, 4 Sep 87 18:01:15 PDT.STJOHNS> In-Reply-To: <8709042059.AA06511@columbia-pdn> No, no, no!!! DO NOT extend the meaning of the USER command or for that matter that of the PASS command. They have very specific meanings. Instead, create your own extension commands "XCPW" and "XGRP". These can be specified via the "quote" command that is supposed to be part of all FTP implementations. This is within the scope of the standard. Please, be sensible - standards are there for a reason, interoperability. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090412513200> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Fri 4 Sep 87 11:22:11-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA07899; Fri, 4 Sep 87 09:30:17 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: 4 Sep 87 12:51:32 GMT From: mtune!codas!ablnc!gil@RUTGERS.EDU (Gil Widdowson) Organization: AT&T, Maitland, Florida Subject: HELP: select() under sockets Message-Id: <311@ablnc.ATT.COM> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa I am trying to modify an application to use select(3w) to manage incoming data. I am working on 3B2s, 3B20s, and UTS using sockets under Wollongong's/AT&T's TCP/IP over Ethernet. 3Bs are running TCP release 1.1. Anyway, it does not seem to work at all. So I set up a little client/server model where the server uses select() to determine when the client has sent it data on an established virtual circuit. When I use block mode, it pends forever, though if I break out using sbd(1), data is there. If I use timed polling mode, it always returns zero forever. Is it me or our sockets service?? code fragment ... set up connection on file descriptor nfd /* *********************************************** ** Select test code ** if timed_select FALSE ** pend until our fd is ready for readying ** else ** do polling once a second ** until our fd is ready for readying *********************************************** */ readfds = (1< Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cam@columbia-pdn (Chris Markle acc_gnsc) Newsgroups: comp.protocols.tcp-ip Subject: Re: Multiple 331 passwd responses in FTP protocol Message-ID: <8709042059.AA06511@columbia-pdn> Date: Fri, 4-Sep-87 16:59:07 EDT Article-I.D.: columbia.8709042059.AA06511 Posted: Fri Sep 4 16:59:07 1987 Date-Received: Sat, 5-Sep-87 20:42:29 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 28 Folks, A number of people have quickly pointed out to me that section 5.4 "Sequencing of Commands and Replies" in RFC 959 specifically states the responses that are valid after a PASS command, and guess what, 331 is not one of them. So, if the password specified on the PASS command has expired we will do the following: 1) send a "530 passwd expired; retry with passwd/newpasswd" 2) extend the syntax for the PASS text to allow specification of a new passwd PASS passwd[/newpasswd] [GROUP(xxx)] (GROUP is another piece of user id the user may want to specify in a usual MVS security environment) 3) while we're at it, extend the syntax of the USER command also USER userid[/passwd[/newpasswd]] [GROUP(xxx)] This will screw up 4.x users who use .netrc files to allow auto-login when 4.x client FTP connects to a remote host, in the case where the passwd has expired, but that's life in the big (BLUE) city! Chris Markle - cam@acc-sb-unix.arpa - (301)290-8100 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [85@winfree.UUCP] <1987090416142200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bdale@winfree.UUCP (Bdale Garbee) Newsgroups: rec.ham-radio.packet,comp.os.minix,comp.protocols.tcp-ip Subject: winfree anonymous uucp fixed Message-ID: <85@winfree.UUCP> Date: Fri, 4-Sep-87 20:14:22 EDT Article-I.D.: winfree.85 Posted: Fri Sep 4 20:14:22 1987 Date-Received: Sun, 6-Sep-87 06:19:23 EDT Reply-To: bdale@winfree.UUCP (Bdale Garbee) Organization: Bdale's Berkeley Box, Colorado Springs Lines: 11 To those who have unsuccessfully tried to uucp the KA9Q Internet Package from uucp host winfree as per the information in the release posting... I have fixed the problem that caused requests from unknown hosts to fail. Two sites have gotten the bits this afternoon, so I think it's fixed. If you tried before and it bombed, try again now with the same login info! -- Bdale Garbee, N3EUA phone: 303/593-9828 h, 303/590-2868 w uucp: {bellcore,crash,hp-lsd,ncc,pitt,usafa,vixie}!winfree!bdale arpa: bdale%winfree.uucp@bellcore.com fido: sysop of 128/19 packet: n3eua @ k0hoa, Colorado Springs ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12332050185.35.ROODE@BIONET-20.ARPA] <1987090416545400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROODE@BIONET-20.ARPA (David Roode) Newsgroups: comp.protocols.tcp-ip Subject: Re: request for mailer information Message-ID: <12332050185.35.ROODE@BIONET-20.ARPA> Date: Fri, 4-Sep-87 20:54:54 EDT Article-I.D.: BIONET-2.12332050185.35.ROODE Posted: Fri Sep 4 20:54:54 1987 Date-Received: Sat, 5-Sep-87 22:31:04 EDT References: <8709031718.AA02339@utkcsunix.CS.UTK.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 I think you are refering to a mail user agent rather than a mailer. A mailer is usually the delivery agent and the interface to the transports used. I too would like to see a better mail program. However, perhaps you would find the MM program available for Unix and VMS which is derived on the version for TOPS-20 to be superior to what you are using. I suggest contacting Kashtan@IU.AI.SRI.COM for more information. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[SRI-NIC.ARPA]Fri,.4.Sep.87.18:01:15.PDT.STJOHNS] <1987090417010000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: STJOHNS@SRI-NIC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: Multiple 331 passwd responses in FTP protocol Message-ID: <[SRI-NIC.ARPA]Fri,.4.Sep.87.18:01:15.PDT.STJOHNS> Date: Fri, 4-Sep-87 21:01:00 EDT Article-I.D.: <[SRI-NIC.ARPA]Fri,.4.Sep.87.18:01:15.PDT.STJOHNS> Posted: Fri Sep 4 21:01:00 1987 Date-Received: Sat, 5-Sep-87 23:23:40 EDT References: <8709042059.AA06511@columbia-pdn> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 No, no, no!!! DO NOT extend the meaning of the USER command or for that matter that of the PASS command. They have very specific meanings. Instead, create your own extension commands "XCPW" and "XGRP". These can be specified via the "quote" command that is supposed to be part of all FTP implementations. This is within the scope of the standard. Please, be sensible - standards are there for a reason, interoperability. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [16393@teknowledge-vaxc.ARPA] <1987090420275200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) Newsgroups: comp.protocols.tcp-ip Subject: Re: request for mailer information Message-ID: <16393@teknowledge-vaxc.ARPA> Date: Sat, 5-Sep-87 00:27:52 EDT Article-I.D.: teknowle.16393 Posted: Sat Sep 5 00:27:52 1987 Date-Received: Sat, 5-Sep-87 23:21:08 EDT References: <12332050185.35.ROODE@BIONET-20.ARPA> Organization: Teknowledge, Inc., Palo Alto CA Lines: 22 > perhaps you would find the MM program available for Unix and VMS > which is derived on the version for TOPS-20 to be superior > to what you are using. I suggest contacting Kashtan@IU.AI.SRI.COM > for more information. TOPS20 MM is a fine program in its environment. Unix MM doesn't feel like Unix: it feels like a little TOPS20 island plopped into the midst of Unix. You may consider that a plus. I don't. It uses its own format for mail files, different from what Unix mail uses, so I haven't found a way to make it read Unix mail files. (It reads incoming mail into ~/mail.txt, making alterations to suit its format in the process.) MM also seems to think that "/" is a TOPS20 switch metacharacter or some such, so it doesn't understand Unix pathnames. The built-in help uses TOPS20 terminology to the extent of referring to documentation files in TOPS20 syntax (e.g., DOC:BAR.DOC;1). Mike Khaw -- internet: mkhaw@teknowledge-vaxc.arpa usenet: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709051947.AA00913@ucbvax.Berkeley.EDU] <1987090511364600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: comp.protocols.tcp-ip Subject: Re: Multiple 331 password responses in FTP protocol Message-ID: <8709051947.AA00913@ucbvax.Berkeley.EDU> Date: Sat, 5-Sep-87 15:36:46 EDT Article-I.D.: ucbvax.8709051947.AA00913 Posted: Sat Sep 5 15:36:46 1987 Date-Received: Sun, 6-Sep-87 06:25:33 EDT References: <8709041634.AA11908@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 From my reading of this topic I could not tel if the password was being changed on a high frequency basis (like hourly) or on a low frequency basis (like monthly). If monthly, then returning an error is probably fine, but if it is hourly (or less) then something has to change so the user does not get completely frustrated. What are the facts? Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090511364601> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sat 5 Sep 87 12:41:58-PDT Date: 5 Sep 1987 15:36:46 EDT Subject: Re: Multiple 331 password responses in FTP protocol From: Dan Lynch To: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) cc: tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU In-Reply-To: <8709041634.AA11908@topaz.rutgers.edu> From my reading of this topic I could not tel if the password was being changed on a high frequency basis (like hourly) or on a low frequency basis (like monthly). If monthly, then returning an error is probably fine, but if it is hourly (or less) then something has to change so the user does not get completely frustrated. What are the facts? Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [749@ucdavis.UUCP] <1987090520024600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sun%iris@ucdavis.UUCP (Yvonne Sun) Newsgroups: comp.protocols.tcp-ip Subject: problem on "select()" Message-ID: <749@ucdavis.UUCP> Date: Sun, 6-Sep-87 00:02:46 EDT Article-I.D.: ucdavis.749 Posted: Sun Sep 6 00:02:46 1987 Date-Received: Sun, 6-Sep-87 20:03:06 EDT Sender: uucp@ucdavis.UUCP Reply-To: sun@iris (Yvonne Sun) Distribution: world Organization: University of California, Davis Lines: 25 Systems: 4.3 BSD UNIX, ULTRIX 1.2, Sun UNIX 4.2 Machines: VAX 750, VAX 8600, Sun 2 I have a problem in my program. In one of the routines, I use "select" on several opened(including tcp and upd sockets) sockets and a pseudo- terminal device inside a for loop. One of the sockets(call it S) is a passive one, i.e. it is there to accept connections from other tcp sockets. If S is selected, an "accept" will be executed, trying to accept the connection. Since "select" is used, S should be selected only when there is a pending connection request. My problem is that, after the program is executed for a while, socket S is always selected and the accept call will return unsuccessfully with the error code being 60( i.e. ETIMEOUT). After that, S will be selected again and again and accept will fail every time it is called. What troubles me is that S is selected even I haven't tried to connect to it. I am sure that I reset the input mask used in the select everytime right before select is called. Have you seen something like that before? Or do you have any idea about what causes this phenomenon? I would appreciate any opinion and suggestions. Yvonne Sun at UC Davis address: sun@iris.ucdavis.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709061618.AA14584@topaz.rutgers.edu] <1987090608185400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: HELP: select() under sockets Message-ID: <8709061618.AA14584@topaz.rutgers.edu> Date: Sun, 6-Sep-87 12:18:54 EDT Article-I.D.: topaz.8709061618.AA14584 Posted: Sun Sep 6 12:18:54 1987 Date-Received: Sun, 6-Sep-87 21:14:36 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 The definition of the first argument to the socket is the maximum file descriptor that can be specified in any of the other fields. You set it to one (presumably because you are assuming the value was supposed to be the number of things selecting on). Setting this value to one means that you can only select on file descriptor 0. Set the value to something larger like the maximum number of file descriptors (NFILE). -ROn ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709071137.AA25232@ucbvax.Berkeley.EDU] <1987090703380700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: murayama@CS.UCL.AC.UK (Yuko Murayama) Newsgroups: comp.protocols.tcp-ip Subject: ISO8473 vs. IP Message-ID: <8709071137.AA25232@ucbvax.Berkeley.EDU> Date: Mon, 7-Sep-87 07:38:07 EDT Article-I.D.: ucbvax.8709071137.AA25232 Posted: Mon Sep 7 07:38:07 1987 Date-Received: Tue, 8-Sep-87 02:08:02 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Could anyone let me know about the difference between ISO 8473 (protocol for providing the connectionless-mode network service) and the DARPA IP? Yuko Murayama a Ph.D. student Dept of Computer Science University College London ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709071307.AA25918@ucbvax.Berkeley.EDU] <1987090704540000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: NS-DDN@DDN3.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: ACC's FTP Protocol Modification Proposal Message-ID: <8709071307.AA25918@ucbvax.Berkeley.EDU> Date: Mon, 7-Sep-87 08:54:00 EDT Article-I.D.: ucbvax.8709071307.AA25918 Posted: Mon Sep 7 08:54:00 1987 Date-Received: Tue, 8-Sep-87 02:11:51 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Mike, by "quote", don't you mean a command at the topmost UI layer, not the PI layer which the RFC lays down the law for? The RFC provides the "SITE" command for local vagarities. Since I see nothing in the RFC which would preclude the SITE command before the USER command, I should think that would be the way for ACC to go with this interoperable difficulty. However, I am in total agreement with your strong statement on the bending of command syntax. Chris, I would think again about supporting this type of service. Although the FTP protocol is intentionally designed for interactive use by the owner of the password, the world is obviously moving toward unattended file transfer (and other traditionally interactive tasks). The better approach is to insist that the security system merely request the user to change his password and continue to accept the existing password until the human being explicitly changes it. Note that if several batch FTPs are queued and the first one changes the password, the remaining FTPs will fail... Best regards, Dave Craig Network Solutions, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090704540001> Received: from ddn3.arpa by SRI-NIC.ARPA with TCP; Mon 7 Sep 87 06:02:24-PDT Date: 7 Sep 87 08:54 EDT From: NS-DDN @ DDN3.arpa Subject: Re: ACC's FTP Protocol Modification Proposal To: STJOHNS @ SRI-NIC.ARPA, cam @ ACC-SB-UNIX.ARPA CC: tcp-ip @ SRI-NIC.ARPA Mike, by "quote", don't you mean a command at the topmost UI layer, not the PI layer which the RFC lays down the law for? The RFC provides the "SITE" command for local vagarities. Since I see nothing in the RFC which would preclude the SITE command before the USER command, I should think that would be the way for ACC to go with this interoperable difficulty. However, I am in total agreement with your strong statement on the bending of command syntax. Chris, I would think again about supporting this type of service. Although the FTP protocol is intentionally designed for interactive use by the owner of the password, the world is obviously moving toward unattended file transfer (and other traditionally interactive tasks). The better approach is to insist that the security system merely request the user to change his password and continue to accept the existing password until the human being explicitly changes it. Note that if several batch FTPs are queued and the first one changes the password, the remaining FTPs will fail... Best regards, Dave Craig Network Solutions, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2536@okstate.UUCP] <1987090710445600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ks@a.cs.okstate.edu (Kurt F. Sauer) Newsgroups: comp.protocols.tcp-ip Subject: Re: Multiple 331 password responses in FTP protocol Message-ID: <2536@okstate.UUCP> Date: Mon, 7-Sep-87 14:44:56 EDT Article-I.D.: okstate.2536 Posted: Mon Sep 7 14:44:56 1987 Date-Received: Wed, 9-Sep-87 07:28:24 EDT References: <8709041634.AA11908@topaz.rutgers.edu> Reply-To: ks@okstate.UUCP (Kurt F. Sauer) Organization: Decision Studies Group, Inc., Box 701401, Tulsa OK 74170-1401 Lines: 64 Keywords: trusted path; ftp (file transfer protocol) Summary: Agrees that FTP is not the right place for password changes, and provides some suggestions for design criteria, with referen In article <8709041634.AA11908@topaz.rutgers.edu>, Ron Natalie writes: >Beyond that conceptual problem, if I understand what is going on here, >you're second password string actually changes the password? This is >a horrendous security problem and really ought not to be done in FTP. >Better to just return an error (EXPIRED PASSWORD) and leave the user >to correct the situation through other channels. I absolutely concur. Implementations of FTP were designed to perform file transfers, not the changing of authenticators used in login situations. This leaves one with a situation where subversion of local software (not normally regarded as a trusted implementation) would render distant-end protection useless. I suggest you think this design issue out with a security engineer, and I suspect that the median solution will probably be something like Ron's suggestion above. We would never allow user programs to control foreign host access; this is somewhat akin to doing just that. A couple of guidelines which might be helpful from a more generic stand- point: [PassMgtGuide85] 4.2.2.3 [Password] Change Procedure ...If the change is necesary due to an expired password, the user should be so informed. The user should be pre- sented with a brief summary of the major steps in changing a password, including a caution that the user should ensure that no one else is watching what the user is doing. ... The user should then enter the new password twice so the procedure can verify that the user can con- sistently enter the password correctly. The new password should be obliterated by techniques such as overprinting or terminal screen erasing. ... While it is true that many (tho not all!) UNIX implementations include a passwd program that gives instructions, some do. The more important con- sideration is immediate: Few FTP implementations here (none?) keep the value supplied for ACCT from being displayed. Further, it's true that several implementations of FTP don't even protect the PASS value when it's entered (unlike 4.3bsd UNIX implementations)! 4.3.2 [Password] Entry ... It is recommended that the system not echo pass- words that users type in. When the system cannot pre- vent a password from being echoed ..., it is recommen- ded that a random overprint mask be printed before or after the password is entered, as appropriate, to con- ceal the typed password. The complete password as entered by the user should be an exact match, character for character, with the user's current password. And, of course, using the ACCT feature won't allow for retyping the password for correctness, which is a big "lose." Think this out again and let us know what you decide. Kurt F. Sauer Tulsa, OK ---------- References: [PassMgtGuide85] National Computer Security Center, _ D_ e_ p_ a_ r_ t_ m_ e_ n_ t_ _ o_ f_ _ D_ e_ f_ e_ n_ s_ e _ P_ a_ s_ s_ w_ o_ r_ d_ _ M_ a_ n_ a_ g_ e_ m_ e_ n_ t_ _ G_ u_ i_ d_ e_ l_ i_ n_ e, Report CSC-STD-002-85 (Fort George G. Meade, MD: NCSC), April 1985. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [434@hubcap.UUCP] <1987090711171800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hubcap@hubcap.UUCP (Mike S Marshall) Newsgroups: comp.protocols.tcp-ip Subject: CMU/tektronix tcp/ip software... Message-ID: <434@hubcap.UUCP> Date: Mon, 7-Sep-87 15:17:18 EDT Article-I.D.: hubcap.434 Posted: Mon Sep 7 15:17:18 1987 Date-Received: Tue, 8-Sep-87 03:06:52 EDT Organization: Clemson University, Clemson, SC Lines: 12 Keywords: where can I get it? greetings... The answer to my question has been posted before, but alas, I didn't care then :-). Who can I contact to get the CMU/tek tcp/ip sofware... Can I run it in shared deqna mode on a microvax? Is it really a good, well documented product? thanks -Mike Marshall hubcap@hubcap.clemson.edu ...!hubcap!hubcap ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090712215100> Received: from Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Mon 7 Sep 87 04:29:31-PDT Received: from ucl-cs-pyr1 by nss.Cs.Ucl.AC.UK via Ethernet with SMTP id aa05508; 7 Sep 87 12:26 BST Date: Mon, 7 Sep 87 12:21:51 GMT-0:00 From: Yuko Murayama To: iso@nrtc.northrop.com, tcp-ip@sri-nic.arpa cc: murayama@Cs.Ucl.AC.UK Subject: ISO8473 vs. IP Could anyone let me know about the difference between ISO 8473 (protocol for providing the connectionless-mode network service) and the DARPA IP? Yuko Murayama a Ph.D. student Dept of Computer Science University College London ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU].8-Sep-87.05:05:46.GBELING] <1987090801050000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: GBELING@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: unbix or rmx Message-ID: <[A.ISI.EDU].8-Sep-87.05:05:46.GBELING> Date: Tue, 8-Sep-87 05:05:00 EDT Article-I.D.: <[A.ISI.EDU].8-Sep-87.05:05:46.GBELING> Posted: Tue Sep 8 05:05:00 1987 Date-Received: Wed, 9-Sep-87 04:42:37 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 hello, can anyone help me answer the following questions: a) how small can an unix-system be made which should run on an 80286 processor ( from intel) ? b) when using rmx (from intel) as operating system instead are ther the protocols telnet/tcp/ip available somewhere ? thanks gerd beling west-germany ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709081306.AA11132@gateway.mitre.org] <1987090805062200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya) Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP Message-ID: <8709081306.AA11132@gateway.mitre.org> Date: Tue, 8-Sep-87 09:06:22 EDT Article-I.D.: gateway.8709081306.AA11132 Posted: Tue Sep 8 09:06:22 1987 Date-Received: Wed, 9-Sep-87 03:47:25 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 The simple reply is that they are very similar functionally, but different in terms of header format and all that. I would be hard pressed to say what the important differences were since that depends on ones priorities. However, the ISO8473 address is much bigger (up to 20 bytes vs. 4 for DoD IP). I like the partial source routing of ISO8473 because I am involved in routing. However, that feature can bite you if you are not careful, and I wouldn't be surprized if it never gets widely implemented. If one consideres ICMP to part and parcel of DoD IP, then there are a couple more differences. ICMP has the Echo function, which ISO8473 does not, and has the Redirect. However, ISO9542 (the ES-IS routing protocol for use with ISO8473) has the redirect function, so its tit for tat. I will be interested to see what others perceive as the major differences between the two. I have never sat down and made a blow by blow comparison. Paul Tsuchiya tsuchiya@gateway.mitre.org The MITRE Corp. tsuchiya@mitre-gateway.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2370001@b-mrda] <1987090806010000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jim@b-mrda Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP and Unix file servers Message-ID: <2370001@b-mrda> Date: Tue, 8-Sep-87 10:01:00 EDT Article-I.D.: b-mrda.2370001 Posted: Tue Sep 8 10:01:00 1987 Date-Received: Fri, 11-Sep-87 07:31:56 EDT Lines: 15 does anyone know of a unix file server for pc's that uses the intelligent ethernet cards, as intelligent cards, with TCP/IP protocols and msnet support ? Or am I asking for to much ??? jim sadler 206-575-7125 hpubvwa!b-mrda!jim P.O. Box 3707 ms 9C-38 Seattle, Wa. USA 98124 Any opinions expressed are mine and mine only and not that of my employer. Also add in whatever else should be said at this point. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [121600001@datacube] <1987090807490000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: berger@datacube.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Terminal Server Questions? Message-ID: <121600001@datacube> Date: Tue, 8-Sep-87 11:49:00 EDT Article-I.D.: datacube.121600001 Posted: Tue Sep 8 11:49:00 1987 Date-Received: Fri, 11-Sep-87 00:49:37 EDT Lines: 28 Nf-ID: #N:datacube:121600001:000:1400 Nf-From: datacube.UUCP!berger Sep 8 11:49:00 1987 Looking for recommendations and suggestions on a Ethernet - TCP/IP Serial port sever. These are the gadets that concentrate and connect several RS-232 ports to a TCP/IP ethernet backbone. We have a network of Sun's, Pyramid, generic 68020 Unix and OS-9 systems as well as PC's on our network. We have run out of genric serial ports and are looking at this as a mechanism to distribute serial ports around the company. We have an immediate need for additional ports, but we are thinking that for the mondo growth we are experiencing that we will standardize on using these concentrators for connecting serial ports to various Unix boxes. Is this a good idea? The serial port traffic is primairly terminals but a chunk of the traffic is high speed binary download modules. We are looking at the Encore Annex, the Cisco ASM Communications Server and the Micom Ethernet Terminal Server. Are there others out there worth looking at? Are there known good/bad things about the above devices? I'm looking for tips, hints and experiences. Please send via E-Mail and I will synopsize to the net. Bob Berger Datacube Inc. Systems / Software Group 4 Dearborn Rd. Peabody, Ma 01960 VOICE: 617-535-6644; FAX: (617) 535-5643; TWX: (710) 347-0125 UUCP: berger@datacube.COM, ihnp4!datacube!berger {seismo,cbosgd,cuae2,mit-eddie}!mirror!datacube!berger ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709081602.AA25281@mars.mitre.org] <1987090808022000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bhanji@GATEWAY.MITRE.ORG Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP Message-ID: <8709081602.AA25281@mars.mitre.org> Date: Tue, 8-Sep-87 12:02:20 EDT Article-I.D.: mars.8709081602.AA25281 Posted: Tue Sep 8 12:02:20 1987 Date-Received: Wed, 9-Sep-87 04:46:18 EDT References: <8709081252.AA10860@gateway.mitre.org> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 28 Date: Mon, 7 Sep 87 12:21:51 GMT-0:00 From: Yuko Murayama Could anyone let me know about the difference between ISO 8473 (protocol for providing the connectionless-mode network service) and the DARPA IP? Yuko Murayama a Ph.D. student Dept of Computer Science University College London A document put out by the National Research Council in 1985 briefly describes the differences between the DoD IP and ISO IP pp 18-24. The report is mostly dedicated to the comparison between TCP and TP4 but has a small section on the two IP comparison. "Transport Protocols for Department of Defense Data Networks", Report to the Department of Defense and the Bureau of Standards. Committee on Computer-Computer Communication Protocols, Board on Telecommunications and Computer Applications, Commission on Engineering and Technical Systems, National Research Council. NATIONAL ACADEMY PRESS, Washington, D.C. February 1985. Hope this is helpful. Shiraz Bhanji. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3176@b-tech.UUCP] <1987090808044500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: zeeff@b-tech.UUCP (Jon Zeeff) Newsgroups: comp.protocols.tcp-ip Subject: Re: Where can I find SLIP server for 4.2/3? Message-ID: <3176@b-tech.UUCP> Date: Tue, 8-Sep-87 12:04:45 EDT Article-I.D.: b-tech.3176 Posted: Tue Sep 8 12:04:45 1987 Date-Received: Thu, 10-Sep-87 07:30:53 EDT References: <8708300436.AA03739@beno.CSS.GOV> Reply-To: zeeff@b-tech.UUCP (Jon Zeeff) Organization: Branch Technology Ann Arbor, MI Lines: 22 In article <8708300436.AA03739@beno.CSS.GOV> rick@SEISMO.CSS.GOV (Rick Adams) writes: > >Note: SLIP is ONLY a device driver. You have to come up with >your own IP, TCP, ICMP, ETC > So it seems that to use 4.xbsd machine as a slip server (ie. I want a 4.x machine to talk to a PC via slip, giving a PC network access), there would be some simple software needed to pass packets from the slip driver to the regular ip driver. Has anyone written such software? >To answer the other popular question, no there is no RFC describing the >"protocol" (I hesitate to call it a protocol. Its a simple framing >scheme.) Perhaps there is some other documentation of the framing scheme? -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709081637.AA03204@janeb.wisc.edu] <1987090808375500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hagens@JANEB.WISC.EDU (Robert Hagens) Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP Message-ID: <8709081637.AA03204@janeb.wisc.edu> Date: Tue, 8-Sep-87 12:37:55 EDT Article-I.D.: janeb.8709081637.AA03204 Posted: Tue Sep 8 12:37:55 1987 Date-Received: Wed, 9-Sep-87 05:48:41 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 29 Comparison of DoD IP and ISO IP: As Paul pointed out, functionally the same. Here are some other differences: - No upper layer protocol ID in ISO8473. - Headers in ISO8473 can be 255 octets (vs. 60 for DoD IP). - Support of header parameters is optional in ISO8473, mandatory in DoD IP. - Time to live in ISO8473 is 1/2 sec as opposed to 1 sec for DoD IP. (It will still end up being used as a hop count.) - No timestamp parameter in ISO8473. - Fixed part of ISO8473 header has odd byte aligned, 2 byte fields. - DoD IP fragmentation is called segmentation in ISO. Identical function, however all ISO8473 optional parameters are carried with fragment. (Called a derived PDU). Only in ISO8473: - Error Report PDU. Sent when a data PDU is discarded. Almost identical to data pdu except it contains the reason for discard. Data of error report PDU is header of discarded PDU. Error report contains ICMP functionality of destination unreachable, ttl expired and parameter problem. - 'congestion experienced'. Set by a router, when a router experiences congestion. The two biggest differences I see are the address part and lack of upper layer proto id. Rob Hagens UW Madison Computer Science ----MESSAGE-END---- ----MESSAGE-BEGIN---- [423@root44.co.uk] <1987090808384500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jgh@root.co.uk (Jeremy G Harris) Newsgroups: comp.protocols.tcp-ip,comp.unix.wizards,comp.bugs.4bsd Subject: IP options Message-ID: <423@root44.co.uk> Date: Tue, 8-Sep-87 12:38:45 EDT Article-I.D.: root44.423 Posted: Tue Sep 8 12:38:45 1987 Date-Received: Thu, 10-Sep-87 06:46:55 EDT Organization: Root Computers Ltd., London, England Lines: 33 Keywords: IP option network bug route Are there any known problems in the 4.3 code dealing with IP options? I can't understand it.... Specifically, in routine ip_dooptoptions, file ip_input.c: 1) Strict source route with record appears to record an address for the receiving interface rather than the transmitting one. 2) Record route appears to route the datagram based on a garbage address, bouncing an ICMP "source route failed" if this fails or recording an address for the bogus transmitting interface if it succeeds. Are these bugs or have I missed something? Has anybody fixed them? Does anybody use IP options anyway? Do I have an out-of-date RFC? Thanks in antici... . . . pation, Jeremy Reference: RFC 791: IP protocol spec. Sept '81 pp. 20,21 "... address as known in the environment into which this datagram is being forwarded" (identical wording in two places) -- Jeremy Harris jgh@root.co.uk ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709081702.AA00208@apolling.imagen.uucp] <1987090809024400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: geof@apolling.UUCP (Geof Cooper) Newsgroups: comp.protocols.tcp-ip Subject: Re: Re: HELP: select() under sockets Message-ID: <8709081702.AA00208@apolling.imagen.uucp> Date: Tue, 8-Sep-87 13:02:44 EDT Article-I.D.: apolling.8709081702.AA00208 Posted: Tue Sep 8 13:02:44 1987 Date-Received: Wed, 9-Sep-87 06:17:53 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: imagen!geof@decwrl.dec.com Organization: The ARPA Internet Lines: 37 > The definition of the first argument to the socket is the maximum file > descriptor that can be specified in any of the other fields. You set > it to one (presumably because you are assuming the value was supposed to > be the number of things selecting on). Setting this value to one means > that you can only select on file descriptor 0. Set the value to something > larger like the maximum number of file descriptors (NFILE). Umm, I just looked into /usr/include/stdio.h on our apollo system: Changelog entry: 10/01/82 jrw increased _NFILE from 20 to 128..... So using NFILE is probably NOT the way to go, unless you declare readfds, et al as arrays (this leads one to wonder, of course, why the existing apollo software works at all -- since I know of no code that actually uses arrays with select. Probably because no one actually opens more than 32 file descriptors and only THEN creates a socket...). In a separate note to Mr. Widdowson, I suggested: min( 8 * (sizeof readfds), NFILE ) so that the argument really does reflect the size of the data being passed to it. Actually, 8 * (sizeof readfds) is probably sufficient, since you will never actually turn on a bit that is beyond NFILE (hmmm... maybe little-endian vs big-endian affects things... comments?). Unfortunately, this is non-portable, since the size of a char is not necessarily 8 bits. But I suspect that all network software would break if char != octet. - Geof ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709081802.AA15351@gateway.mitre.org] <1987090810021300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya) Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP Message-ID: <8709081802.AA15351@gateway.mitre.org> Date: Tue, 8-Sep-87 14:02:13 EDT Article-I.D.: gateway.8709081802.AA15351 Posted: Tue Sep 8 14:02:13 1987 Date-Received: Wed, 9-Sep-87 06:20:07 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 33 > > Comparison of DoD IP and ISO IP: > > As Paul pointed out, functionally the same. Here are some other differences: > > - No upper layer protocol ID in ISO8473................... > > The two biggest differences I see are the address part and lack of > upper layer proto id. > > Rob Hagens > UW Madison Computer Science > This is not to say that ISO8473 cannot distinguish between upper layer protocols. The address in ISO8473 is used to do the distinguishing (the address is called the Network Service Access Point Address, which defines the boundary between the transport thing and the network thing. I don't want to get into what "thing" is). Practically speaking, one reserves a byte (sorry, octet) in the NSAP address, usually called the NSAP selector, to do the job of the protocol id field in DoD IP. Boils down to the same thing as far as I can tell. (I'm wondering if it is kosher to use the NSAP selector byte to distinguish between different transport classes (TP0, TP1, ...., TP4). Something tells me it isn't, but I don't see how someone could stop you. I'll have to bring that up at the next 3.3 meeting). Paul Tsuchiya tsuchiya@gateway.mitre.org The MITRE Corp. tsuchiya@mitre-gateway.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709081838.AA16085@gateway.mitre.org] <1987090810382100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tsuchiya@gateway.mitre.ORG (Paul Tsuchiya) Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP Message-ID: <8709081838.AA16085@gateway.mitre.org> Date: Tue, 8-Sep-87 14:38:21 EDT Article-I.D.: gateway.8709081838.AA16085 Posted: Tue Sep 8 14:38:21 1987 Date-Received: Wed, 9-Sep-87 06:28:58 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 36 > From: "Marty Schoffstall" > Status: R > > > - 'congestion experienced'. Set by a router, when a router > experiences congestion. > > The infamous "DEC Bit", which reports to the recipient of the packet > that there is congestion. This bit has debatable merit, would the > two camps like to expound? > > Marty Ok, I'll bite. The DEC bit is used, at least in DECNET (phase 4 or 5, I don't know) to control the transport window such that the network doesn't get congested. It is a "congestion avoidance" mechanism. As far as I know, the algorithm assumes it knows the round trip time. I don't know if DEC measures this or assumes a value. (I understand the problems associated with trying to measure it.) The algorithm seems to be a good one, and works as long as all of the parts are there and everyone participates. (Please, someone from DEC correct me if I have this screwed up). DEC has released there algorithm for doing this (until recently, it was proprietary). In their IS-IS routing proposal, they have said when to set the bit. I am not sure how or if they intend to standardize the part that tells the transport machine what to do. I suppose this could be done right in ISO, or in one of the profile organizations like COS. Tsuchiya PS. We may be in two camps, but lets face it: if it rains, all of our campfires are going to go out. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709081824.AA09821@nic.nyser.net] <1987090810425200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: schoff@NIC.NYSER.NET ("Marty Schoffstall") Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP Message-ID: <8709081824.AA09821@nic.nyser.net> Date: Tue, 8-Sep-87 14:42:52 EDT Article-I.D.: nic.8709081824.AA09821 Posted: Tue Sep 8 14:42:52 1987 Date-Received: Wed, 9-Sep-87 06:28:09 EDT References: <8709081637.AA03204@janeb.wisc.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 - 'congestion experienced'. Set by a router, when a router experiences congestion. The infamous "DEC Bit", which reports to the recipient of the packet that there is congestion. This bit has debatable merit, would the two camps like to expound? Marty ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709081857.AA16814@topaz.rutgers.edu] <1987090810575500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: unbix or rmx Message-ID: <8709081857.AA16814@topaz.rutgers.edu> Date: Tue, 8-Sep-87 14:57:55 EDT Article-I.D.: topaz.8709081857.AA16814 Posted: Tue Sep 8 14:57:55 1987 Date-Received: Wed, 9-Sep-87 06:39:54 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 I know of no RMX TCP/IP implemenations. However, the XENIX (UNIX) for the 286 doesn't really have TCP/IP either. You can buy inteligent protocol cards from a company like CMC (they have the software for XENIX) to talk to the Ethernet with TCP/IP. You ought to be able to write a RMX interface for this if you know enough about RMX. As for how small XENIX can get? I'm not sure. I only had a single memory card in my 310 but I have no idea how much was on it (a meg?). As for disk space, a minimal system comes on a single floppy disk so that you can load in the rest of the baseline system which comes on around 20 360K floppies. This means that the baseline system takes up less than 7 MEG, but you could probably reduce that even smaller by throwing away things like /usr/dict/words and other large systems that aren't used. UNIX also needs somewhere to swap but you can probably get by with a few meg for this. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1923@umd5.umd.edu] <1987090811452600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: zben@umd5.umd.edu (Ben Cranston) Newsgroups: comp.protocols.tcp-ip Subject: Re: HELP: select() under sockets Message-ID: <1923@umd5.umd.edu> Date: Tue, 8-Sep-87 15:45:26 EDT Article-I.D.: umd5.1923 Posted: Tue Sep 8 15:45:26 1987 Date-Received: Thu, 10-Sep-87 02:07:13 EDT References: <8709061618.AA14584@topaz.rutgers.edu> Reply-To: zben@umd5 (Ben Cranston) Organization: University of Maryland, College Park Lines: 26 Summary: Set first arg to NUMBER OF BITS IN YOUR MASKS! In article <8709061618.AA14584@topaz.rutgers.edu> ron@TOPAZ.RUTGERS.EDU (Ron Natalie) writes: > The definition of the first argument to the socket is the maximum file > descriptor that can be specified in any of the other fields. You set > it to one ... Set the value to something > larger like the maximum number of file descriptors (NFILE). (Hiya Ron!) People have been talking about setting NFILE bigger than 32, so I think it is worth mentioning that the first argument to select is used to tell it the width of the bitmaps in the succeeding arguments. So if they are INTs you probably want to set it to 32. Of course, if your system DOES have NFILE set bigger than 32 and you happen to get a FD with a higher number, that (1<31) diehorribly("fix this mess") else { num = select( 32 , (1< Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rcallon@PARK-STREET.BBN.COM (Ross Callon) Newsgroups: comp.protocols.tcp-ip Subject: re: ISO8473 versus (DARPA) IP Message-ID: <8709082129.AA21571@ucbvax.Berkeley.EDU> Date: Tue, 8-Sep-87 17:16:40 EDT Article-I.D.: ucbvax.8709082129.AA21571 Posted: Tue Sep 8 17:16:40 1987 Date-Received: Wed, 9-Sep-87 07:26:22 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 56 Yuko; I think we need more experience in actually using the ISO IP before we say which differences are the most important, but here are a few that come to mind. I hope this is a useful start. If you are doing a study of the differences between the DARPA IP and the ISO IP, or looking at implementation issues with the ISO IP, I would be very interested in seeing any result which you may come up with. (1) As Paul mentioned, the ISO uses variable length addresses up to 20 octets, while the DOD uses fixed length 4 octet addresses. The ISO addresses are much more flexible. For example, they may be used to explicitly encode something like an "autonomous system" number, and/or the IEEE 802 link address. I think that the difference in addresses make the ISO IP more appropriate for worldwide use with potentially hundreds of thousands of networks, but make it more costly to run (bigger headers and more processing). (2) The IPs use different checksums. The ISO checksum is computationally more costly, but has a higher probability of detecting errors in which only a small number of bits are changed (i.e., random bit errors as opposed to burst errors). In addition, the ISO checksum can be "turned off" by using all zeroes in the checksum field. (3) The ISO IP doesn't have a source quench. This is because at the time no one who went to the meetings where it was defined believed that source quench was useful. (4) The ISO IP has a small difference in the way that source routing is implemented. The "destination address" field in the ISO IP always contains the true final destination address, rather than the "next hop" source routing address. This means that all of the gateways need to implement source routing for it to work (rather than only those gateways which are actually mentioned in the source route). Since implementation of source routing is optional in the ISO IP, it is unlikely that all gateway vendors will actually implement it. (5) The ISO IP doesn't have an echo packet. The idea was that you could get the same effect by source routing a packet to another gateway and then back to yourself. Unfortunately, as mentioned in (4), this is not likely to work since implementation of source routing is optional. People in ANSI are aware of this problem and thus it is likely to be fixed eventually (I hope). (6) The encoding of many of the fields are different. For example, the fields needed for reassembly (fragment offset, etc..) are only present in the ISO IP if fragmentation is permitted. Similarly, the "security" option had to take into account the fact that the ISO IP is standardized for worldwide use, and therefore needs greater flexibility. Generally, the ISO IP has opted for greater flexibility, and the cost of larger packets and possibly greater cost in parsing the headers. Ross ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090813164001> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Tue 8 Sep 87 14:22:11-PDT Date: Tue, 8 Sep 87 17:16:40 EDT From: Ross Callon To: murayama@CS.UCL.AC.UK cc: iso@NRTC.NORTHROP.COM, tcp-ip@SRI-NIC.ARPA Subject: re: ISO8473 versus (DARPA) IP Yuko; I think we need more experience in actually using the ISO IP before we say which differences are the most important, but here are a few that come to mind. I hope this is a useful start. If you are doing a study of the differences between the DARPA IP and the ISO IP, or looking at implementation issues with the ISO IP, I would be very interested in seeing any result which you may come up with. (1) As Paul mentioned, the ISO uses variable length addresses up to 20 octets, while the DOD uses fixed length 4 octet addresses. The ISO addresses are much more flexible. For example, they may be used to explicitly encode something like an "autonomous system" number, and/or the IEEE 802 link address. I think that the difference in addresses make the ISO IP more appropriate for worldwide use with potentially hundreds of thousands of networks, but make it more costly to run (bigger headers and more processing). (2) The IPs use different checksums. The ISO checksum is computationally more costly, but has a higher probability of detecting errors in which only a small number of bits are changed (i.e., random bit errors as opposed to burst errors). In addition, the ISO checksum can be "turned off" by using all zeroes in the checksum field. (3) The ISO IP doesn't have a source quench. This is because at the time no one who went to the meetings where it was defined believed that source quench was useful. (4) The ISO IP has a small difference in the way that source routing is implemented. The "destination address" field in the ISO IP always contains the true final destination address, rather than the "next hop" source routing address. This means that all of the gateways need to implement source routing for it to work (rather than only those gateways which are actually mentioned in the source route). Since implementation of source routing is optional in the ISO IP, it is unlikely that all gateway vendors will actually implement it. (5) The ISO IP doesn't have an echo packet. The idea was that you could get the same effect by source routing a packet to another gateway and then back to yourself. Unfortunately, as mentioned in (4), this is not likely to work since implementation of source routing is optional. People in ANSI are aware of this problem and thus it is likely to be fixed eventually (I hope). (6) The encoding of many of the fields are different. For example, the fields needed for reassembly (fragment offset, etc..) are only present in the ISO IP if fragmentation is permitted. Similarly, the "security" option had to take into account the fact that the ISO IP is standardized for worldwide use, and therefore needs greater flexibility. Generally, the ISO IP has opted for greater flexibility, and the cost of larger packets and possibly greater cost in parsing the headers. Ross ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709082214.AA03199@trout.nosc.mil] <1987090814143500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: carrs@TROUT.NOSC.MIL (Stephen M. Carr) Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP Message-ID: <8709082214.AA03199@trout.nosc.mil> Date: Tue, 8-Sep-87 18:14:35 EDT Article-I.D.: trout.8709082214.AA03199 Posted: Tue Sep 8 18:14:35 1987 Date-Received: Thu, 10-Sep-87 00:50:45 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 62 ------- Ref: (a) National Research Council, "Transport Protocols for Department of Defense Data Networks", RFC942, National Academy Press, Washington, D.C., February 1985 Yuko, 1. Reference (a) document which Shiraz Bhanji referred to is online at sri-nic.arpa. The path name is RFC942.TXT. So if you have FTP capability, you can download it. It is in excess of 217,000 bytes. 2. I am assuming that you don't have FTP capability from your host into the ARPANET/MILNET. Therefore, if you would like, I or one of your colleagues could try to forward it to you via SMTP. 3. Here is a list of other recent RFCs which might interest you on related subjects. All of these documents are online in the same directory. RFC INDEX (RFC1008) Jun 87 (McCoy) Implementation Guide for the ISO Transport Protocol (RFC1007) Jun 87 (McCoy) Military Supplement to the ISO Transport Protocol (RFC1006) May 87 (Rose) ISO Transport Services on top of the TCP Version:3 (Obsoletes RFC 983) (RFC995) Jan 87 (ANSIx353.3) End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473 (RFC994) Jan 87 (ANSIx353.3) Final Text of DIS 8473, Protocol for Providing the Connectionless Mode Network Service (Obsoletes RFC 926) (RFC962) ... Nov 85 (Padlipsky) TCP-4 Prime (RFC945) ... Apr 85 (Postel) DOD Statement on NRC Report (RFC942) ... Mar 85 (NRC) Transport Protocols for Department of Defense Data Networks (RFC939) ... Feb 85 (NRC) Executive Summary of the NRC Report on Transport Protocols for Department of Defense Data Networks (RFC905) ... Apr 84 (ISO) ISO Transport Protocol Specification (ISO DP 8073) (Obsoletes RFC 892) 4. I hope this is of some help. Steve Carr LCDR, SC, USN Navy Management Systems Support Office (Code 33C) Naval Air Station Norfolk, Virginia 23511-6694 DDN: carrs@trout.nosc.mil DDN: navmasso30tc@nardacva.arpa ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709082240.AA25121@columbia-pdn] <1987090814401700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cam@columbia-pdn (Chris Markle acc_gnsc) Newsgroups: comp.protocols.tcp-ip Subject: Once More on FTP Password Expiration, Etc. Message-ID: <8709082240.AA25121@columbia-pdn> Date: Tue, 8-Sep-87 18:40:17 EDT Article-I.D.: columbia.8709082240.AA25121 Posted: Tue Sep 8 18:40:17 1987 Date-Received: Thu, 10-Sep-87 01:05:56 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 86 Folks, I thought I could lay this subject to rest after my last response but people still seem confused by what we're talking about here. The average security package for MVS implements facilities to age passwords and to not allow the user access to the system after his password has expired UNLESS a new password is also provided; note that the expired password must still be provided WITH a new password in order to login. These packages also allow the user to change his/her password for whatever reason. In addition, a user may exist in multiple "groups", each of which permits the user different access privileges. These features are part of the security package and are not a creation of ACC or ACCES/MVS (our software). Now, given this, all well-behaved IBM subsystems that gather a userid/password and validate that against the security system, provide a way for the user to specify an optional new password and group at signon. The new password can be specified to change your existing password at any time, or to change your password if the old one has expired. The group can be specified to select a group from the set of groups in which that user is a member. This list of well-behaved subsystems is large and includes CICS, IMS, TSO, and NCCF. In other words, the standard MVS environment supports the sort of thing we're talking about here; we at ACC are merely trying to integrate our product into that environment. Regarding the notion that ACC has proposed an "FTP protocol modification": 1) The current FTP specs suggest that the USER/PASS command arguments are "that which is required by the SERVER for access to its file system". The specs do not say that the USER or PASS arguments take any particular form. In fact, the USER argument is specified as a string of any of the 128 ASCII characters except CR and LF; ditto for the PASS argument. In my opinion, the argument "oldpass/newpass GROUP(xxx)" does not violate or modify the FTP spec. I am suggesting (strongly) that this is valid syntax for a PASS argument, per the spec; whether or not this fits your notion of what a userid or password "looks like" depends on whether you regularly work on an MVS system or not. Regarding the notion that we are creating a Server FTP that will not interoperate with other Client FTP implementations: 1) Assuming that you are the average user who is only in one group and whose password is not expired, all you will need to send our server is "USER chris" and "PASS chris-pswd", just as is done now. Even if you are in multiple groups, there is a default group associated with each user that will be in effect if no group is specified. I see no interoperability problem here. Regarding specification of new passwords and groups via the SITE command, I see two problems: 1) Not all FTP Client implementations provide a SITE command, which is understandable, but worse, not all those non-SITE providers provide a "quote" facility either. 2) The use of the SITE command to provide new password group information creates a second, unrelated place where this information must be specified; the logical, intuitive place is in the USER/PASS command text. Regarding the notion that people could access the MVS system via Telnet to change their password if it expired: 1) This doesn't address the need to optionally specify a group name together with a userid. 2) A site may allow a user to use the MVS system through FTP but not allow the user access to any subsystem (eg. TSO, CICS, IMS) which would allow him to change his password. Clearly this sort of user would have limited capabilites, but it is not hard to envision this sort of environment. Regarding ignoring the expired password condition and allowing the user to login anyway: 1) This would not be popular with MVS customers that want to mandate the use of aged passwords. MVS security auditors are not very keen on making exceptions for certain security situations. In conclusion, all ACC is trying to do is to integrate ACCES/MVS into the MVS environment as a well-behaved software product (from the MVS perspective). So long as we do this without violating the FTP spec (which I contend we haven't) and without affecting interoperability with other implementations (which I contend we don't) we should be free to make our product fit as nicely and logically into MVS as possible. Chris Markle - cam@acc-sb-unix.arpa - (301)290-8100 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709082303.AA23518@ucbvax.Berkeley.EDU] <1987090814430000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CDC-DDN@DDN3.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Sendmail message delays and timeout Message-ID: <8709082303.AA23518@ucbvax.Berkeley.EDU> Date: Tue, 8-Sep-87 18:43:00 EDT Article-I.D.: ucbvax.8709082303.AA23518 Posted: Tue Sep 8 18:43:00 1987 Date-Received: Thu, 10-Sep-87 01:04:59 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 We are having a problem using UNIX 4.3 sendmail. It will send messages to our CYBER quickly (1 sec) for a while, and then will gradually take longer and longer to send a message until finally it takes so long (7 minutes) to send the message that some UNIX timer kicks in and aborts the connection. When this happens, all subsequent messages time out in this manner, and we cannot send messages to the CYBER until we re-boot the VAX. We have looked at this with both an Ethernet analyzer and using the debug facility within sendmail. In the slow transactions, there is a delay of several minutes between the time that UNIX TCP receives the 354 reply to the DATA command, and the time that UNIX TCP sends the message text. The delay is always at this one point, and there is no other difference between slow and fast transactions. Even in sessions that time out, the sendmail debug output indicates that sendmail believes it has sent the message text, but it never appears on the Ethernet. There are no retransmission packets or ICMP messages to indicate some lower-level problem. Does anyone know what might be causing this problem? Any pointers will be appreciated. Mike Sanders CDC-DDN@DDN3 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090814430001> Received: from ddn3.arpa by SRI-NIC.ARPA with TCP; Tue 8 Sep 87 15:55:40-PDT Date: 8 Sep 87 18:43 EDT From: CDC-DDN @ DDN3.arpa Subject: Sendmail message delays and timeout To: tcp-ip @ sri-nic.arpa CC: cdc-ddn @ ddn3 We are having a problem using UNIX 4.3 sendmail. It will send messages to our CYBER quickly (1 sec) for a while, and then will gradually take longer and longer to send a message until finally it takes so long (7 minutes) to send the message that some UNIX timer kicks in and aborts the connection. When this happens, all subsequent messages time out in this manner, and we cannot send messages to the CYBER until we re-boot the VAX. We have looked at this with both an Ethernet analyzer and using the debug facility within sendmail. In the slow transactions, there is a delay of several minutes between the time that UNIX TCP receives the 354 reply to the DATA command, and the time that UNIX TCP sends the message text. The delay is always at this one point, and there is no other difference between slow and fast transactions. Even in sessions that time out, the sendmail debug output indicates that sendmail believes it has sent the message text, but it never appears on the Ethernet. There are no retransmission packets or ICMP messages to indicate some lower-level problem. Does anyone know what might be causing this problem? Any pointers will be appreciated. Mike Sanders CDC-DDN@DDN3 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709090100.AA06470@emptys.cc.umich.edu] <1987090817001500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mts@EMPTYS.CC.UMICH.EDU (Michael T. Stolarchuk) Newsgroups: comp.protocols.tcp-ip Subject: Re: HELP: select() under sockets Message-ID: <8709090100.AA06470@emptys.cc.umich.edu> Date: Tue, 8-Sep-87 21:00:15 EDT Article-I.D.: emptys.8709090100.AA06470 Posted: Tue Sep 8 21:00:15 1987 Date-Received: Thu, 10-Sep-87 01:40:38 EDT References: <8709081702.AA00208@apolling.imagen.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 34 Umm, I just looked into /usr/include/stdio.h on our apollo system: Changelog entry: 10/01/82 jrw increased _NFILE from 20 to 128..... So using NFILE is probably NOT the way to go, unless you declare readfds, et al as arrays (this leads one to wonder, of course, why the existing apollo software works at all -- since I know of no code that actually uses arrays with select. Probably because no one actually opens more than 32 file descriptors and only THEN creates a socket...). How about 4.3? Where select is: nfound = select(nfds, readfds, writefds, exceptfds, timeout) int nfound, nfds; fd_set *readfds, *writefds, *exceptfds; struct timeval *timeout; And you have: FD_SET(fd, &fdset) FD_CLR(fd, &fdset) FD_ISSET(fd, &fdset) FD_ZERO(&fdset) And fd_set is: typedef struct fd_set { fd_mask fds_bits[howmany(FD_SETSIZE, NFDBITS)]; } fd_set; And FD_SETSIZE is 256. mts. the snail. imagine him at 100 mhp. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709090159.AA01763@acetes.dec.com] <1987090817590000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mogul@DECWRL.DEC.COM (Jeffrey Mogul) Newsgroups: comp.protocols.tcp-ip Subject: More on RARP under 4.x BSD Message-ID: <8709090159.AA01763@acetes.dec.com> Date: Tue, 8-Sep-87 21:59:00 EDT Article-I.D.: acetes.8709090159.AA01763 Posted: Tue Sep 8 21:59:00 1987 Date-Received: Thu, 10-Sep-87 01:50:49 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 40 > From: bbanerje@sjuvax.UUCP (B. Banerjee) ... > c. Rarp can be added to 4.3 BSD. ... > You can write a rarp daemon > with the aid of the 'enet' ethernet packet filter software that > was part of the ``user contributed software '' that came with 4.3 > BSD. Yes, probably. I doubt that the "enet" code distributed on the 4.3 tapes will actually work without modification (actually, the modification required is to the interface driver code for whatever interface you are using). As Greg Satz said in a recent message, you can probably get the working code from someone at Stanford ... but I don't know who (it is NOT either Greg or myself, so don't bother asking). People at Stanford (different people, probably) also have a "rarpd" that uses the packet filter. You could try to get that, although it really is a fairly simple program to write. > I personally believe that it makes the most sense to place the > rarp handling stuff along with the 'arp' handling stuff in the > kernel (netinet/if_ether.c). Unfortunately, this is infeasible in a large campus, since the ARP tables in the kernel are meant to be small and, when the overflow, it is normally safe to throw away old entries (they will be restored if they are used again). At a site like Stanford, where there may be hundreds or even thousands of diskless workstations eventually, the current kernel ARP table is clearly not going to work. RARP is not a performance-critical protocol; a user-mode server is the right way to go. It's sad that 4.xBSD has no mechanism to write such servers (i.e., no link-level access mechanism); that's what the packet filter or NIT is meant to provide. With such a mechanism, it's trivial to put the RARP server in the right place. Maybe 4.4BSD will do something about this. -Jeff Mogul (co-author of the packet filter code and of the RARP RFC) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709090249.aa09372@Huey.UDEL.EDU] <1987090822492400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP Message-ID: <8709090249.aa09372@Huey.UDEL.EDU> Date: Wed, 9-Sep-87 02:49:24 EDT Article-I.D.: Huey.8709090249.aa09372 Posted: Wed Sep 9 02:49:24 1987 Date-Received: Thu, 10-Sep-87 07:20:07 EDT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Marty, The "congestion experienced" bit has to be a good idea, since it has been suggested repeatedly by Jack Haverty (name one) and several others at BBN for darn near ten years. So, let's do it. We need to swipe a bit from the IP header. Any suggestions on which one? That bit decided, give me ten seconds and the fuzzballs will concur in the madness... Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU].9-Sep-87.06:13:59.CERF] <1987090902130000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP Message-ID: <[A.ISI.EDU].9-Sep-87.06:13:59.CERF> Date: Wed, 9-Sep-87 06:13:00 EDT Article-I.D.: <[A.ISI.EDU].9-Sep-87.06:13:59.CERF> Posted: Wed Sep 9 06:13:00 1987 Date-Received: Fri, 11-Sep-87 01:43:14 EDT References: <8709081824.AA09821@nic.nyser.net> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 RE: DEC Bit (Congestion Experienced) When I talked with Tony Lauck about this notion, the idea was that you could tell the receiving party "sooner" than the sending party about this congestion problem and that the receiving party might use the window mechanism to reduce the sender's ambition level until the congestion had died away. The sender probably needs to know about the congestion explicitly, too, if there is any option for re-routing the traffic from the origin via an alternate path which is less congested. It would be helpful to hear from Digital about their experiences with the dynamics of their DECNET with and without the use of this signal. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090902130001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 9 Sep 87 03:15:54-PDT Date: 9 Sep 1987 06:13-EDT Sender: CERF@A.ISI.EDU Subject: Re: ISO8473 vs. IP From: CERF@A.ISI.EDU To: schoff@NIC.NYSER.NET Cc: hagens%janeb.spool.wisc.edu@GREMLIN.NRTC.NORTHROP.COM Cc: iso@NRTC.NORTHROP.COM, murayama@CS.UCL.AC.UK Cc: tcp-ip@SRI-NIC.ARPA, tsuchiya@GATEWAY.MITRE.ORG Message-ID: <[A.ISI.EDU] 9-Sep-87 06:13:59.CERF> In-Reply-To: <8709081824.AA09821@nic.nyser.net> RE: DEC Bit (Congestion Experienced) When I talked with Tony Lauck about this notion, the idea was that you could tell the receiving party "sooner" than the sending party about this congestion problem and that the receiving party might use the window mechanism to reduce the sender's ambition level until the congestion had died away. The sender probably needs to know about the congestion explicitly, too, if there is any option for re-routing the traffic from the origin via an alternate path which is less congested. It would be helpful to hear from Digital about their experiences with the dynamics of their DECNET with and without the use of this signal. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709091102.AA17931@nic.nyser.net] <1987090903112800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: schoff@NIC.NYSER.NET ("Marty Schoffstall") Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP Message-ID: <8709091102.AA17931@nic.nyser.net> Date: Wed, 9-Sep-87 07:11:28 EDT Article-I.D.: nic.8709091102.AA17931 Posted: Wed Sep 9 07:11:28 1987 Date-Received: Fri, 11-Sep-87 00:46:00 EDT References: <8709090249.aa09372@Huey.UDEL.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 34 The "congestion experienced" bit has to be a good idea, since it has been suggested repeatedly by Jack Haverty (name one) and several others at BBN for darn near ten years. So, let's do it. We need to swipe a bit from the IP header. Any suggestions on which one? That bit decided, give me ten seconds and the fuzzballs will concur in the madness... Dave, I don't know how to take the above message. I don't believe I have a fully-formed opinion on this due to the fact that I have not seen the DEC "paper" however I have some philosophical questions about this in the ISO stack: Isn't this mechanism a bit indirect? Does anyone have some thoughts about latency in a live ISO INTERNET?. Your transmitter is hosing the net, Mr. Gateway (whoops IS), 4 PDN's away determines there is congestion toggles the bit and we arrive at the receiver. The receiver then takes this Layer3 information exports it to the Layer4 machine who does something bright with it like communicating with the transmitter Layer4. [ My recollection of this is that Layer4 had to be TP4, ie this wasn't going to be effective for other transports.] This mechanism seems right for at least experimental use in the DOD INTERNET, a small alteration of a mature operational protocol. However, it looks like a hack in the ISO stack if the ISO stack is supposed to have been an improvement on what we've learned in the last 10 years.... Dave, how do you feel this should affect the TCP if implemented in the DOD stack? Marty ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090903383900> Received: from gateway.mitre.org by SRI-NIC.ARPA with TCP; Wed 9 Sep 87 04:42:08-PDT Return-Path: Received: by gateway.mitre.org (5.54/SMI-2.2) id AA00370; Wed, 9 Sep 87 07:38:39 EDT Date: Wed, 9 Sep 87 07:38:39 EDT From: tsuchiya@gateway.mitre.org (Paul Tsuchiya) Full-Name: Paul Tsuchiya Message-Id: <8709091138.AA00370@gateway.mitre.org> To: Mills@udel.edu, schoff@nic.nyser.net Subject: Re: ISO8473 vs. IP Cc: , Schoffstall@nic.nyser.net, iso@nrtc.northrop.com, murayama@cs.ucl.ac.uk, tcp-ip@sri-nic.arpa > From: "Marty Schoffstall" > Status: R > > Isn't this mechanism a bit indirect? Does anyone have some > thoughts about latency in a live ISO INTERNET?. > Your transmitter is hosing the net, Mr. Gateway > (whoops IS), 4 PDN's away determines there is > congestion toggles the bit and we arrive at > the receiver. The receiver then takes this > Layer3 information exports it to the Layer4 > machine who does something bright with it > like communicating with the transmitter Layer4. > [ My recollection of this is that Layer4 had > to be TP4, ie this wasn't going to > be effective for other transports.] > > Marty The algorithm doesn't work quite like that. In fact, the bit is set roughly half the time, and all it takes is one packet in the queue to set the bit. Setting it half the time has the result of getting the most information out of it (information theory). So it is not like there is a problem and then the bit is set to relieve the problem. Instead, the bit is continuously set to achieve a smooth and appropriate flow of data into the net. I.e., we neven (hopefully) reach the point where a transmitter is hosing the net in the first place. Paul Tsuchiya tsuchiya@gateway.mitre.org The MITRE Corp. tsuchiya@mitre-gateway.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709091149.AA18264@nic.nyser.net] <1987090904044800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: schoff@NIC.NYSER.NET ("Marty Schoffstall") Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP Message-ID: <8709091149.AA18264@nic.nyser.net> Date: Wed, 9-Sep-87 08:04:48 EDT Article-I.D.: nic.8709091149.AA18264 Posted: Wed Sep 9 08:04:48 1987 Date-Received: Fri, 11-Sep-87 01:06:14 EDT References: <8709091138.AA00370@gateway.mitre.org> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 This paragraph isn't clear to me.... The algorithm doesn't work quite like that. In fact, the bit is set roughly half the time, and all it takes is one packet in the queue to set the bit. Setting it half the time has the result of getting whose queue? the most information out of it (information theory). So it is not like there is a problem and then the bit is set to relieve the problem. What is the algorithm for setting the bit then? When everything is fine? Instead, the bit is continuously set to achieve a smooth and appropriate flow of data into the net. I.e., we neven (hopefully) reach the point where a transmitter is hosing the net in the first place. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709091226.AA29150@gyre.umd.edu] <1987090904262100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: chris@GYRE.UMD.EDU (Chris Torek) Newsgroups: comp.protocols.tcp-ip Subject: Re: HELP: select() under sockets Message-ID: <8709091226.AA29150@gyre.umd.edu> Date: Wed, 9-Sep-87 08:26:21 EDT Article-I.D.: gyre.8709091226.AA29150 Posted: Wed Sep 9 08:26:21 1987 Date-Received: Fri, 11-Sep-87 01:15:17 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Please read the select(2) manual entry on your 4.3BSD machine to see how 4.3BSD defines select() (it is backwards compatible with 4.2BSD's definition through an implementation trick only). (You might mentally substitute `properly cast NULL' for `zero pointer' while you are reading...) Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709091233.AA01229@gateway.mitre.org] <1987090904333500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tsuchiya@gateway.mitre.ORG (Paul Tsuchiya) Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP Message-ID: <8709091233.AA01229@gateway.mitre.org> Date: Wed, 9-Sep-87 08:33:35 EDT Article-I.D.: gateway.8709091233.AA01229 Posted: Wed Sep 9 08:33:35 1987 Date-Received: Fri, 11-Sep-87 01:16:05 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 31 After all of this talking about the DEC scheme, I bloody well hope that DEC gives me a good job offer. I didn't want to get into details over the air. I have the breifing slides from a presentation given at the IETF in Boston last (I think it was) April. They are fairly self explanatory. Mainly, I wanted to dispel this notion that congestion control should occur when there is congestion. It should actually occur before there is congestion, and that is what the DEC algorithm does. The bit is set by gateways, and they set it whenever they have one packet in the queue. I believe this does not mean one packet per source/destination pair or anything like that, simply one packet. The bit is set in the queued packet, which means that the host receiving the set bit is not the one that sent the packet, but the one on the other end. However, that one tells the sending one to shrink its window via the normal method, and this is how the congestion information gets back to the sending host. Of course, the hosts have an algorithm they use to know how to adjust the flow. Basically, the window is increased additively and decreased multiplicatively. Also, the hosts filter by considering x number of previous bits. Again, an appeal to DEC people: please correct me if I have over-simplified, misrepresented, or in any other way screwed this up. Paul Tsuchiya tsuchiya@gateway.mitre.org The MITRE Corp. tsuchiya@mitre-gateway.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709091251.AA01568@gateway.mitre.org] <1987090904514800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tsuchiya@gateway.mitre.ORG (Paul Tsuchiya) Newsgroups: comp.protocols.tcp-ip Subject: errata (DECBIT) Message-ID: <8709091251.AA01568@gateway.mitre.org> Date: Wed, 9-Sep-87 08:51:48 EDT Article-I.D.: gateway.8709091251.AA01568 Posted: Wed Sep 9 08:51:48 1987 Date-Received: Fri, 11-Sep-87 01:17:09 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 This from Charles Hedrick, who was kind enough to not broadcast it: > Are you sure? As I recall, the DEC bit is set by any router when the > queue has more than one item in it. I didn't think the RTT was involved. > It's main disadvantage seemed to be that its resolution wasn't very good, > so a large number of simultaneous connections could confuse it. Right you are. I don't know how the idea of RTT got into my head. (Actually I do, but I don't want to say). So much for my spiffy job offer from DEC. How about a lawsuit instead. Paul Tsuchiya tsuchiya@gateway.mitre.org The MITRE Corp. tsuchiya@mitre-gateway.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709091358.AA07288@ucbvax.Berkeley.EDU] <1987090905360000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: NS-DDN@DDN3.ARPA Newsgroups: comp.protocols.tcp-ip Subject: MVS FTP Server Access Message-ID: <8709091358.AA07288@ucbvax.Berkeley.EDU> Date: Wed, 9-Sep-87 09:36:00 EDT Article-I.D.: ucbvax.8709091358.AA07288 Posted: Wed Sep 9 09:36:00 1987 Date-Received: Fri, 11-Sep-87 01:26:43 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Chris, I apologize to you and this conference for terming your proposal an FTP protocol modification. I was wrong, and you were right regarding the syntax of the USER and PASS command arguments. Your syntax does make more sense than using a SITE command, but you may find some user FTPs that are unable to support it. That's life in the big (Internet) city. I would propose that ALL MVS software use a consistent access methodology as hammered out through appropriate facilities, in the spirit of interoperability. Perhaps an RFC is called for. What do people think? Best regards, Dave Craig Network Solutions, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090905360001> Received: from ddn3.arpa by SRI-NIC.ARPA with TCP; Wed 9 Sep 87 06:53:20-PDT Date: 9 Sep 87 09:36 EDT From: NS-DDN @ DDN3.arpa Subject: MVS FTP Server Access To: cam @ ACC-SB-UNIX.ARPA CC: tcp-ip @ SRI-NIC.ARPA Chris, I apologize to you and this conference for terming your proposal an FTP protocol modification. I was wrong, and you were right regarding the syntax of the USER and PASS command arguments. Your syntax does make more sense than using a SITE command, but you may find some user FTPs that are unable to support it. That's life in the big (Internet) city. I would propose that ALL MVS software use a consistent access methodology as hammered out through appropriate facilities, in the spirit of interoperability. Perhaps an RFC is called for. What do people think? Best regards, Dave Craig Network Solutions, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090905505700> Received: from CC5.BBN.COM by SRI-NIC.ARPA with TCP; Wed 9 Sep 87 09:46:16-PDT To: CERF@A.ISI.EDU, tsuchiya@GATEWAY.MITRE.ORG cc: schoff@NIC.NYSER.NET, hagens%janeb.spool.wisc.edu@GREMLIN.NRTC.NORTHROP.COM, iso@NRTC.NORTHROP.COM, murayama@CS.UCL.AC.UK, tcp-ip@SRI-NIC.ARPA, malis@CC5.BBN.COM Subject: Re: ISO8473 vs. IP In-reply-to: Your message of 09 Sep 87 06:13:00 -0400. <[A.ISI.EDU] 9-Sep-87 06:13:59.CERF> Date: Wed, 09 Sep 87 12:30:57 -0400 From: Andy Malis Paul, Vint, or whoever else can help, Is there a reference available for a description of this DECNET congestion control mechanism, now that it is no longer proprietary? Thanks, Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [090987.094643.PERSHNG@ibm.com] <1987090906264400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERSHNG@IBM.COM (John Pershing) Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <090987.094643.PERSHNG@ibm.com> Date: Wed, 9-Sep-87 10:26:44 EDT Article-I.D.: ibm.090987.094643.PERSHNG Posted: Wed Sep 9 10:26:44 1987 Date-Received: Fri, 11-Sep-87 01:41:07 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 I don't understand why one should trust "subverted local software" to handle your *current* password, yet not trust it to set a *new* password. (Note that the current password has to be provided before the new one can be set.) The scheme the Chris Markle proposes for setting new passwords makes perfect sense to someone who is familiar with the normal IBM access control procedures. (Actually, the *original* scheme makes *more* sense, except that the perpetrators of FTP don't seem to understand the necessity of periodic password changes.) However, the GROUP() parameter on the PASS command seems a bit strange -- wouldn't it "look better" on the USER command, without echo-suppression? John A. Pershing Jr. IBM T. J. Watson Research Center Yorktown Heights, NY 10598 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709091533.AA08771@ucbvax.Berkeley.EDU] <1987090907220000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hsw@TYCHO.ARPA (Howard Weiss) Newsgroups: comp.protocols.tcp-ip Subject: ACC Customer Service Message-ID: <8709091533.AA08771@ucbvax.Berkeley.EDU> Date: Wed, 9-Sep-87 11:22:00 EDT Article-I.D.: ucbvax.8709091533.AA08771 Posted: Wed Sep 9 11:22:00 1987 Date-Received: Fri, 11-Sep-87 01:48:44 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Someone from ACC once posted a customer service address for themselves. Could I that address re-posted - I thought it was customer.service at acc-sb-unix.arpa, but mail that I send to that address gets returned to me by acc-sb-unix.arpa. Thanks, Howard Weiss ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090907220001> Received: from TYCHO.ARPA by SRI-NIC.ARPA with TCP; Wed 9 Sep 87 08:28:32-PDT Date: 9 Sep 1987 1122-EDT Subject: ACC Customer Service From: hsw@TYCHO.ARPA (Howard Weiss) To: tcp-ip at sri-nic.arpa Someone from ACC once posted a customer service address for themselves. Could I that address re-posted - I thought it was customer.service at acc-sb-unix.arpa, but mail that I send to that address gets returned to me by acc-sb-unix.arpa. Thanks, Howard Weiss ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709091649.AA15765@topaz.rutgers.edu] <1987090908491100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@topaz.rutgers.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Once More on FTP Password Expiration, Etc. Message-ID: <8709091649.AA15765@topaz.rutgers.edu> Date: Wed, 9-Sep-87 12:49:11 EDT Article-I.D.: topaz.8709091649.AA15765 Posted: Wed Sep 9 12:49:11 1987 Date-Received: Fri, 11-Sep-87 04:25:00 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Weell, sorry, but the proper approach is not to allow the user to log in when the password is expired. Having passwords that don't really expire (just require the user to change them when they log in) are of no use whatsoever. Regardless of what the normal session login does, this cruft does not belong in FTP. As one of your customers, I suggest that you take this under advice. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709091653.AA15944@topaz.rutgers.edu] <1987090908535100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@topaz.rutgers.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: HELP: select() under sockets Message-ID: <8709091653.AA15944@topaz.rutgers.edu> Date: Wed, 9-Sep-87 12:53:51 EDT Article-I.D.: topaz.8709091653.AA15944 Posted: Wed Sep 9 12:53:51 1987 Date-Received: Fri, 11-Sep-87 04:26:19 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 The other arguments to select are pointers to bit fields so assumably char buf[10]; select(80, buf, (char *) 0, (char *) 0, (char *) 0, (time_t) 0) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709091654.AA10280@ucbvax.Berkeley.EDU] <1987090908592600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: malis@CC5.BBN.COM (Andy Malis) Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP Message-ID: <8709091654.AA10280@ucbvax.Berkeley.EDU> Date: Wed, 9-Sep-87 12:59:26 EDT Article-I.D.: ucbvax.8709091654.AA10280 Posted: Wed Sep 9 12:59:26 1987 Date-Received: Fri, 11-Sep-87 04:21:28 EDT References: <[A.ISI.EDU].9-Sep-87.06:13:59.CERF> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Paul, Vint, or whoever else can help, Is there a reference available for a description of this DECNET congestion control mechanism, now that it is no longer proprietary? Thanks, Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12333275160.15.NIC@SRI-NIC.ARPA] <1987090909035300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: NIC@SRI-NIC.ARPA (DDN Reference) Newsgroups: comp.protocols.tcp-ip Subject: DDN MGT Bulletin #34 Message-ID: <12333275160.15.NIC@SRI-NIC.ARPA> Date: Wed, 9-Sep-87 13:03:53 EDT Article-I.D.: SRI-NIC.12333275160.15.NIC Posted: Wed Sep 9 13:03:53 1987 Date-Received: Fri, 11-Sep-87 04:27:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 171 ********************************************************************** DDN MGT Bulletin 34 DCA DDN Defense Communications System 9 Sep 87 Published by: DDN Network Info Center (NIC@SRI-NIC.ARPA) (800) 235-3155 DEFENSE DATA NETWORK MANAGEMENT BULLETIN The DDN MANAGEMENT BULLETIN is distributed online by the DDN Network Information Center under DCA contract as a means of communicating official policy, procedures and other information of concern to management personnel at DDN facilities. Back issues may be read through the TACNEWS server ("@n" command at the TAC) or may be obtained by FTP (or Kermit) from the SRI-NIC host [26.0.0.73 or 10.0.0.51] using login="anonymous" and password="guest". The pathname for bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the bulletin number). ********************************************************************** ANNOUNCEMENT OF PSN UPGRADE To all ARPANET users, Node Site Coordinators, and Host Administrators: New versions of software are being released to the ARPANET backbone network over the next six weeks. This will cause minimal disruption to the user community, but will require reloading of all Packet Switching Nodes (PSN) on the ARPANET. The software is referred to as PSN 7.0 and contains the implementation of the new End to End protocols. A mailbox has been set up at BBNCC for questions and comments regarding this software upgrade. The E-mail address is arpaupgrade@bbn.com. The standard procedure to call the BBNCC Hotline for problems will still be in effect. The Toll free number is 1-800-492-4992. The implementation of this software will happen in 2 phases. The 1st phase of the PSN 7.0 implementation will require site coordination and cooperation. All sites will have to place the new cassettes with boot programs into their PSN's during their scheduled reboot. Sites will be notified by the ARPANET Monitoring Center, Cambridge, MA for details and specific times for their scheduled upgrade. New cassette tapes will be sent to the individual node site coordinators. This phase of the transition moves the network from the current version (PSN 6.0) to PSN 7.0 with the new End to End protocol's not configured. Individual site upgrades will take approximately 15 minutes. Phase II of the implementation will be the cutover to the New End to End protocols. The initial upgrade to PSN 7.0 and subsequent cutovers will happen in the order specified in the schedule below. Please be aware that during the cutover period to new End to End, that said node group will be logically segmented for a 2-3 hour test period from the test of the ARPANET. Any questions or comments can also be directed to Mark Whitney at BBNCC (617) 497-2874 or Annette Bauman at DCA (703) 265-5459. Schedule: Event: 09/24/87-09/26-87 Node group 1 sites will be upgraded to PSN 7.0. 09/24-87-10/02/87 Resolve any outstanding issues with these sites. 10/01/87-10/03/87 Node groups 2 thru 5 upgraded to PSN 7.0. 10/03/87-10/10/87 Resolve any outstanding issues with these sites. 10/10/87 All ARPANET nodes running PSN 7.0 with new End to End protocols NOT configures. 10/10/87-10/17/87 Verify all operational procedures. 10/17/87 Node group 1 turnover to new End to End, operation verified and return to the old End to End. 10/17/87-10/24/87 Resolve any outstanding issues with above cutover. 10-24-87 The rest of the node groups cutover to new End to End, operation verified and returned to old End to End. 10/24/87-10/31-87 Resolve any outstanding issues with above cutover. 10/31/87 Entire ARPANET cutover to use new End to End protocols, operation verified, and return to the old End to End mode of operation. 10/31/87-11/07/87 Resolve any outstanding issues with above cutover. 11/07/87 Entire ARPANET cutover to new End to End protocols and left running. 11/07/87... Statistical collection and analysis begins. Group 1 1. Node 79 DEC 2. Node 28 ARPA 3. Node 78 BERK 4. Node 38 BRAGG 5. Node 5 BBN5 6. Node 77 MIT77 7. Node 7 RAND 8. Node 2 SRI2 9. Node 6 MIT6 10. Node 91 UDEL 11. Node 20 DCEC 12. Node 14 CMU Group 2 1. Node 1 UCLA 2. Node 22 ISI22 3. Node 27 ISI27 4. Node 52 ISI52 5. Node 68 LBL2 6. Node 82 BBN82 7. Node 107 SRI107 8. Node 119 ARADC 9. Node 126 NSA2 Group 3 1. Node 25 CSS 2. Node 32 XEROX 3. Node 44 MIT44 4. Node 46 COLNS 5. Node 51 SRI51 6. Node 63 BBN63 7. Node 94 WISC 8. Node 121 US121 9. Node 127 N127 Group 4 1. Node 9 HARV 2. Node 15 UROCH 3. Node 31 CCA 4. Node 4 UTAH 5. Node 56 SUMEX 6. Node 62 TEXAS Group 5 1. Node 37 PURDUE 2. Node 80 SAC 3. Node 99 BBN99 4. Node 10 LINC 5. Node 89 COLUM 6. Node 96 UDEL 7. Node 11 STAN 8. Node 54 CIT 9. Node 111 MTR2 10. Node 13 UCOLORADO 11. Node 17 UMARYLAND Group 6 1. Node 115 CAMBRIDGE* *NOTE: This is a temporary node and will cease to exist after the end to end cutover has been completed. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709091349.aa17070@Huey.UDEL.EDU] <1987090909494200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP Message-ID: <8709091349.aa17070@Huey.UDEL.EDU> Date: Wed, 9-Sep-87 13:49:42 EDT Article-I.D.: Huey.8709091349.aa17070 Posted: Wed Sep 9 13:49:42 1987 Date-Received: Fri, 11-Sep-87 05:08:41 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Marty, My remarks should be interpreted with respect to the DARPA context, where I have some idea of what TCP and other bangers might do with it (infer source quench). Yes, is is true that the receiver, not the transmitter, sees the bit; however, our experience has been that the resources being starved are usually the buffer pool, which means the bit would probably be set on either direction at substantially the same frequency. It works either way, since either or both the transmitter or receiver can crank back the window size. I do not want to speculate on the latency of an ISO internet, except to suggest that it will probably be similar to the DARPA internet, whatever that evolves to. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709091906.AA13172@speedy.WISC.EDU] <1987090911063700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: nhall@CS.WISC.EDU Newsgroups: comp.protocols.tcp-ip Subject: dec bit Message-ID: <8709091906.AA13172@speedy.WISC.EDU> Date: Wed, 9-Sep-87 15:06:37 EDT Article-I.D.: speedy.8709091906.AA13172 Posted: Wed Sep 9 15:06:37 1987 Date-Received: Fri, 11-Sep-87 05:24:21 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 I dug out my notes from the IETF-X3S3.3 meeting at which R. Jain, K. Ramakrishnan, and D. Chiu presented their "DEC-bit" talk, and here I find the following references: Jain, IEEE JSAC Oct 1986 Ramakrishnan, Netwroking Symp., Nov 1986 Since I have neither of these references, I don't know if either one gives a description of the full use of the DEC bit, but I'll send the authors a copy of this mail and see if they have published a paper on the subject, for the folks who weren't at the Boston meeting. Nancy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709092004.AA14417@ucbvax.Berkeley.EDU] <1987090911170400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rcallon@PARK-STREET.BBN.COM (Ross Callon) Newsgroups: comp.protocols.tcp-ip Subject: problems with ISO DEC-bit Message-ID: <8709092004.AA14417@ucbvax.Berkeley.EDU> Date: Wed, 9-Sep-87 15:17:04 EDT Article-I.D.: ucbvax.8709092004.AA14417 Posted: Wed Sep 9 15:17:04 1987 Date-Received: Fri, 11-Sep-87 05:29:39 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 43 In the ISO IP, the DEC bit is located in an options field. In particular, the "Quality of Service Maintenance" option contains three possible classes of encodings, one of which is called "globally unique". One bit of this globally unique QOS option is the congestion experience bit. The ISO spec explicitly specifies which functions must be implemented, and which are optionally implemented. Support for the QOS option is not required. Thus not only is the presence of the DEC bit optional, but even if it is there gateways are not required to look at it. In addition, "Congestion Notification" is also optional. Even if the source uses the globally unique QOS option, and the gateways update the DEC bit appropriately, it is not required (at least by IS 8473) that the destination will notify the Transport Implementation. Clearly, optional implementation of the congestion bit is a problem, especially since if some end systems pay attention to it and others ignore it the "good guys" will end up suffering. This may be overcome by requiring use of the DEC bit in implementers agreements (such as produced by the COS). The placement of the bit in an option field means that if you want to use it for all packets you are requiring the gateways to actually parse the options fields for every packet. This increases the processing demand on gateways. This may be okay for low bandwidth internets, but gets more undesirable for higher bandwidths (what constitutes higher bandwidths depends upon how much processing power you are willing to put in your gateways). I don't think the DEC bit has actually been used in an operational environment (does anyone out there know differently?). What we see in the Arpanet seems to be a relatively large number of short and/or discontinuous flows such as electronic mail and telnet traffic. Transport based flow control methods may be more appropriate for a smaller number of longer term flows. The combination of slow start (which is part of the way that the DEC bit is to be used) plus regulating the growth rate of flows on each connection, will prevent short term connections from "jumping in" with a large increment of traffic all at once. However, for very short lived connections, this may be nearly equivalent to simply using a fixed very small window size. This approach also assumes that all users (or at least the users associated with the overwhelming majority of network traffic) will use a window based transport protocol. All of this suggests that the DEC bit is more an interesting research approach for use in some common environments, rather than a proven technique. Ross ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090911170401> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Wed 9 Sep 87 12:58:27-PDT Date: Wed, 9 Sep 87 15:17:04 EDT From: Ross Callon To: iso@NRTC.NORTHROP.COM, tcp-ip@SRI-NIC.ARPA cc: rcallon@PARK-STREET.BBN.COM Subject: problems with ISO DEC-bit In the ISO IP, the DEC bit is located in an options field. In particular, the "Quality of Service Maintenance" option contains three possible classes of encodings, one of which is called "globally unique". One bit of this globally unique QOS option is the congestion experience bit. The ISO spec explicitly specifies which functions must be implemented, and which are optionally implemented. Support for the QOS option is not required. Thus not only is the presence of the DEC bit optional, but even if it is there gateways are not required to look at it. In addition, "Congestion Notification" is also optional. Even if the source uses the globally unique QOS option, and the gateways update the DEC bit appropriately, it is not required (at least by IS 8473) that the destination will notify the Transport Implementation. Clearly, optional implementation of the congestion bit is a problem, especially since if some end systems pay attention to it and others ignore it the "good guys" will end up suffering. This may be overcome by requiring use of the DEC bit in implementers agreements (such as produced by the COS). The placement of the bit in an option field means that if you want to use it for all packets you are requiring the gateways to actually parse the options fields for every packet. This increases the processing demand on gateways. This may be okay for low bandwidth internets, but gets more undesirable for higher bandwidths (what constitutes higher bandwidths depends upon how much processing power you are willing to put in your gateways). I don't think the DEC bit has actually been used in an operational environment (does anyone out there know differently?). What we see in the Arpanet seems to be a relatively large number of short and/or discontinuous flows such as electronic mail and telnet traffic. Transport based flow control methods may be more appropriate for a smaller number of longer term flows. The combination of slow start (which is part of the way that the DEC bit is to be used) plus regulating the growth rate of flows on each connection, will prevent short term connections from "jumping in" with a large increment of traffic all at once. However, for very short lived connections, this may be nearly equivalent to simply using a fixed very small window size. This approach also assumes that all users (or at least the users associated with the overwhelming majority of network traffic) will use a window based transport protocol. All of this suggests that the DEC bit is more an interesting research approach for use in some common environments, rather than a proven technique. Ross ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709092006.AA09597@okeeffe.Berkeley.EDU] <1987090912063000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels) Newsgroups: comp.protocols.tcp-ip Subject: Re: IP options Message-ID: <8709092006.AA09597@okeeffe.Berkeley.EDU> Date: Wed, 9-Sep-87 16:06:30 EDT Article-I.D.: okeeffe.8709092006.AA09597 Posted: Wed Sep 9 16:06:30 1987 Date-Received: Fri, 11-Sep-87 05:31:56 EDT References: <423@root44.co.uk> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 144 As a matter of fact, there are a few oddities in the IP options code in 4.3. Of the two you mentioned, one is a bug (record route used a garbage address which coincidentally works on machines with default routes). You appear to have misunderstood the code for source route, though; look for the call to ip_rtaddr, which locates the outgoing interface address. The other bug of any interest was in IP timestamp handling. Here is a set of diffs to fix the record route bug and several other minor things. Mike *** /nbsd/usr/src/sys/netinet/ip_input.c Thu Jun 5 00:28:15 1986 --- ./ip_input.c Wed Sep 9 11:33:47 1987 *************** *** 5,7 **** * ! * @(#)ip_input.c 7.1 (Berkeley) 6/5/86 */ --- 5,7 ---- * ! * @(#)ip_input.c 7.6.1.1 (Berkeley) 9/9/87 */ *************** *** 302,304 **** if (fp == 0) { ! if ((t = m_get(M_WAIT, MT_FTABLE)) == NULL) goto dropfrag; --- 302,304 ---- if (fp == 0) { ! if ((t = m_get(M_DONTWAIT, MT_FTABLE)) == NULL) goto dropfrag; *************** *** 490,491 **** --- 490,492 ---- + extern struct in_ifaddr *ifptoia(); struct in_ifaddr *ip_rtaddr(); *************** *** 595,597 **** break; ! bcopy((caddr_t)(cp + off), (caddr_t)&ipaddr.sin_addr, sizeof(ipaddr.sin_addr)); --- 596,598 ---- break; ! bcopy((caddr_t)(&ip->ip_dst), (caddr_t)&ipaddr.sin_addr, sizeof(ipaddr.sin_addr)); *************** *** 602,604 **** type = ICMP_UNREACH; ! code = ICMP_UNREACH_SRCFAIL; goto bad; --- 603,605 ---- type = ICMP_UNREACH; ! code = ICMP_UNREACH_HOST; goto bad; *************** *** 620,622 **** } ! sin = (struct in_addr *)(cp+cp[IPOPT_OFFSET]-1); switch (ipt->ipt_flg) { --- 621,623 ---- } ! sin = (struct in_addr *)(cp + ipt->ipt_ptr - 1); switch (ipt->ipt_flg) { *************** *** 630,636 **** goto bad; ! if (in_ifaddr == 0) ! goto bad; /* ??? */ ! bcopy((caddr_t)&IA_SIN(in_ifaddr)->sin_addr, (caddr_t)sin, sizeof(struct in_addr)); ! sin++; break; --- 631,636 ---- goto bad; ! ia = ifptoia(ifp); ! bcopy((caddr_t)&IA_SIN(ia)->sin_addr, (caddr_t)sin, sizeof(struct in_addr)); ! ipt->ipt_ptr += sizeof(struct in_addr); break; *************** *** 638,639 **** --- 638,642 ---- case IPOPT_TS_PRESPEC: + if (ipt->ipt_ptr + sizeof(n_time) + + sizeof(struct in_addr) > ipt->ipt_len) + goto bad; bcopy((caddr_t)sin, (caddr_t)&ipaddr.sin_addr, *************** *** 642,646 **** continue; - if (ipt->ipt_ptr + sizeof(n_time) + - sizeof(struct in_addr) > ipt->ipt_len) - goto bad; ipt->ipt_ptr += sizeof(struct in_addr); --- 645,646 ---- *************** *** 652,654 **** ntime = iptime(); ! bcopy((caddr_t)&ntime, (caddr_t)sin, sizeof(n_time)); ipt->ipt_ptr += sizeof(n_time); --- 652,655 ---- ntime = iptime(); ! bcopy((caddr_t)&ntime, (caddr_t)cp + ipt->ipt_ptr - 1, ! sizeof(n_time)); ipt->ipt_ptr += sizeof(n_time); *************** *** 731,733 **** return ((struct mbuf *)0); ! m = m_get(M_WAIT, MT_SOOPTS); m->m_len = ip_nhops * sizeof(struct in_addr) + IPOPT_OFFSET + 1 + 1; --- 732,736 ---- return ((struct mbuf *)0); ! m = m_get(M_DONTWAIT, MT_SOOPTS); ! if (m == 0) ! return ((struct mbuf *)0); m->m_len = ip_nhops * sizeof(struct in_addr) + IPOPT_OFFSET + 1 + 1; *************** *** 841,843 **** } ! if (ip->ip_ttl < IPTTLDEC) { type = ICMP_TIMXCEED, code = ICMP_TIMXCEED_INTRANS; --- 844,846 ---- } ! if (ip->ip_ttl <= IPTTLDEC) { type = ICMP_TIMXCEED, code = ICMP_TIMXCEED_INTRANS; *************** *** 870,873 **** --- 873,881 ---- * and if packet was not source routed (or has any options). + * Also, don't send redirect if forwarding using a default route + * or a route modfied by a redirect. */ + #define satosin(sa) ((struct sockaddr_in *)(sa)) if (ipforward_rt.ro_rt && ipforward_rt.ro_rt->rt_ifp == ifp && + (ipforward_rt.ro_rt->rt_flags & (RTF_DYNAMIC|RTF_MODIFIED)) == 0 && + satosin(&ipforward_rt.ro_rt->rt_dst)->sin_addr.s_addr != 0 && ipsendredirects && ip->ip_hl == (sizeof(struct ip) >> 2)) { *************** *** 874,876 **** struct in_ifaddr *ia; - extern struct in_ifaddr *ifptoia(); u_long src = ntohl(ip->ip_src.s_addr); --- 882,883 ---- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709092112.AA07299@orville.arpa] <1987090913120600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lekash@ORVILLE.ARPA (John Lekashman) Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP Message-ID: <8709092112.AA07299@orville.arpa> Date: Wed, 9-Sep-87 17:12:06 EDT Article-I.D.: orville.8709092112.AA07299 Posted: Wed Sep 9 17:12:06 1987 Date-Received: Fri, 11-Sep-87 06:04:27 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 One of the two unused bits in the type of service field. I vote for the end bit. This has something to do with the class of service experienced, rather than desired, but thats ok. Maybe the other bit can be set on ack's to indicate congestion experienced on the packet(s) this is an ack for. (After all, its got to get back to the sender somehow. reduced offered window is one way, an explicit bit's another.) john ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12333323539.15.GRAVES@MATHOM.CISCO.COM] <1987090913293800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: GRAVES@MATHOM.CISCO.COM (Bill Graves) Newsgroups: comp.protocols.tcp-ip Subject: cisco Systems customer service Message-ID: <12333323539.15.GRAVES@MATHOM.CISCO.COM> Date: Wed, 9-Sep-87 17:29:38 EDT Article-I.D.: MATHOM.12333323539.15.GRAVES Posted: Wed Sep 9 17:29:38 1987 Date-Received: Fri, 11-Sep-87 06:09:47 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Mail from cisco Systems' customers requesting information or reporting problems may be addressed to customer-service@mathom.cisco.com. Alternatively, problems may be reported at (800)-553-24HR and orders may be placed at (800)-248-NETS. Note that the latter number may eventually mutate to (800)-553-NETS. Normal business lines on a rotary are available at (415)-326-1941. Best regards, Bill Graves graves@mathom.cisco.com ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709092342.AA03527@PHOEBE.CAM.UNISYS.COM] <1987090915422800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jonab@CAM.UNISYS.COM (Jonathan P. Biggar) Newsgroups: comp.protocols.tcp-ip Subject: Question about IP options Message-ID: <8709092342.AA03527@PHOEBE.CAM.UNISYS.COM> Date: Wed, 9-Sep-87 19:42:28 EDT Article-I.D.: PHOEBE.8709092342.AA03527 Posted: Wed Sep 9 19:42:28 1987 Date-Received: Fri, 11-Sep-87 07:19:20 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 I am implementing IP in Ada and have several questions about IP options that are not clearly answered in either RFC 791 or MIL-SPEC 1777: 1) Are the record route and timestamp options modified by the source and destination systems, or are they only modified by gateways? 2) When using either loose or strict source routing, does the next hop or the final destination go in the destination address field of the IP header? For example, if I want to route from host A through B and C to D, is the destination address B with source route C and D, or is the destination address D with source route B and C? 3) Is it legal to have both loose and strict source routing options in the same IP packet? If so, how do you handle this case? Jon Biggar jonab@cam.unisys.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709092321.AA04042@nic.nyser.net] <1987090915475800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: schoff@NIC.NYSER.NET ("Marty Schoffstall") Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP Message-ID: <8709092321.AA04042@nic.nyser.net> Date: Wed, 9-Sep-87 19:47:58 EDT Article-I.D.: nic.8709092321.AA04042 Posted: Wed Sep 9 19:47:58 1987 Date-Received: Fri, 11-Sep-87 07:19:09 EDT References: <8709091349.aa17070@Huey.UDEL.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 My remarks should be interpreted with respect to the DARPA context, where I have some idea of what TCP and other bangers might do with it (infer source quench). Yes, is is true that the receiver, not the transmitter, sees the bit; however, our experience has been that the resources being starved are usually the buffer pool, which means the bit would probably be set on either direction at substantially the same frequency. It works either way, since either or both the transmitter or receiver can crank back the window size. Are you then suggesting a "future DOD INTERNET gateway" should implement this as an option and upon determining "congestion" set the bit for the receiver and source quench the transmitter? Still in the DOD context do you feel that a single queued datagram should set the bit? With our gateways living on the LAN/WAN interface and the current state of our implementations wouldn't the bit always end up being set? (And therefore useless to us as a signpost?) Marty PS: To further the state of the art of Mills'isms: philosophically if I'm in the swamp with my loaded double barrel shotgun, I'm probably not going to call for help until I see the THIRD alligator. DEC seems to be pushing for the sighting of the first alligator. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU].9-Sep-87.22:43:32.CERF] <1987090918430000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP Message-ID: <[A.ISI.EDU].9-Sep-87.22:43:32.CERF> Date: Wed, 9-Sep-87 22:43:00 EDT Article-I.D.: <[A.ISI.EDU].9-Sep-87.22:43:32.CERF> Posted: Wed Sep 9 22:43:00 1987 Date-Received: Sat, 12-Sep-87 06:28:18 EDT References: <8709091149.AA18264@nic.nyser.net> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 3 What we need is a high capacity, low cost hose to hose protocol... Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090918430001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 9 Sep 87 19:45:41-PDT Date: 9 Sep 1987 22:43-EDT Sender: CERF@A.ISI.EDU Subject: Re: ISO8473 vs. IP From: CERF@A.ISI.EDU To: schoff@NIC.NYSER.NET Cc: Mills@LOUIE.UDEL.EDU, iso@NRTC.NORTHROP.COM Cc: murayama@CS.UCL.AC.UK, tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU] 9-Sep-87 22:43:32.CERF> In-Reply-To: <8709091149.AA18264@nic.nyser.net> What we need is a high capacity, low cost hose to hose protocol... Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU].9-Sep-87.22:51:58.CERF] <1987090918510000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP Message-ID: <[A.ISI.EDU].9-Sep-87.22:51:58.CERF> Date: Wed, 9-Sep-87 22:51:00 EDT Article-I.D.: <[A.ISI.EDU].9-Sep-87.22:51:58.CERF> Posted: Wed Sep 9 22:51:00 1987 Date-Received: Sat, 12-Sep-87 06:28:29 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Andy, Tony Lauck, DEC's chief protocol architect, or John Zornig, also at DEC, could probably point you at anything not proprietary. I believe that they've entered recommendations into the ISO forum in this area so the concepts are probably quite open. I don't have John's or Tony's network mailbox IDs readily handy (oh, for a good white pages!), but perhaps someone on TCP-IP can help, or Tony or John may be reading these messages. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090918510001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 9 Sep 87 19:57:35-PDT Date: 9 Sep 1987 22:51-EDT Sender: CERF@A.ISI.EDU Subject: Re: ISO8473 vs. IP From: CERF@A.ISI.EDU To: malis@CC5.BBN.COM Cc: tsuchiya@GATEWAY.MITRE.ORG, schoff@NIC.NYSER.NET Cc: hagens%janeb.spool.wisc.edu@GREMLIN.NRTC.NORTHROP.COM Cc: iso@NRTC.NORTHROP.COM, murayama@CS.UCL.AC.UK Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU] 9-Sep-87 22:51:58.CERF> In-Reply-To: The message of Wed, 09 Sep 87 12:30:57 -0400 from Andy Malis Andy, Tony Lauck, DEC's chief protocol architect, or John Zornig, also at DEC, could probably point you at anything not proprietary. I believe that they've entered recommendations into the ISO forum in this area so the concepts are probably quite open. I don't have John's or Tony's network mailbox IDs readily handy (oh, for a good white pages!), but perhaps someone on TCP-IP can help, or Tony or John may be reading these messages. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709100300.AA07873@hoptoad.uucp] <1987090919004000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: pozar@hoptoad.UUCP (Tim Pozar) Newsgroups: comp.protocols.tcp-ip Subject: request for addition to mailing list Message-ID: <8709100300.AA07873@hoptoad.uucp> Date: Wed, 9-Sep-87 23:00:40 EDT Article-I.D.: hoptoad.8709100300.AA07873 Posted: Wed Sep 9 23:00:40 1987 Date-Received: Sat, 12-Sep-87 05:59:23 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 I hope I am sending to the right slot. I would like to be added to the mailing list. Tim ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987090919093700> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Wed 9 Sep 87 14:32:55-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA16325; Wed, 9 Sep 87 14:25:08 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: 9 Sep 87 19:09:37 GMT From: super.upenn.edu!operations.dccs.upenn.edu!shaffer@RUTGERS.EDU (Earl Shaffer) Organization: University of Pennsylvania Subject: Advanced Computer Communication's Access Product for MVS Message-Id: <1937@super.upenn.edu> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa Does anyone have any first hand knowledge of the Access product from ACC? We are interested in anyone who has looked into using it on their MVS system, or even better, someone who is now using it! The following things are very important: 1) overall impressions 2) any special "site coding" done to modify the default env. 3) smtp experiences 4) interoperability problems Thanks very much, ============================================================================== Earl Shaffer - University of Pennsylvania - Data Communications Department "Time was invented so that everything wouldn't happen at once." Steven Wright ============================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709092329.aa23398@Huey.UDEL.EDU] <1987090919292500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP Message-ID: <8709092329.aa23398@Huey.UDEL.EDU> Date: Wed, 9-Sep-87 23:29:25 EDT Article-I.D.: Huey.8709092329.aa23398 Posted: Wed Sep 9 23:29:25 1987 Date-Received: Sat, 12-Sep-87 06:14:41 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Marty, I'm not sure a headlong leap on the DEC bit would be appropriate for the existing IP gateway munchkins, but something like this has been proposed to indicate "congestion experienced." The particular method used to determine when gateway has too much kin to munch may depend on the gateway queueing discipline, preemption policy and whether the interfaces are blocking or not, etc. If I understand the DEC bit, the bit is set on a packet that arrives for a queue with at least one packet already queued. Now, from queueing theory, we can compute for each level of traffic the probability that the queue has n customers for each n. A clever end system can then work this backwards to estimate (crudely!) the level of traffic when the bit is set. It's a nice idea and should be tried in an experiment. However, there are lots of other ideas that should be tried, too. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [89@winfree.UUCP] <1987090921594800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bdale@winfree.UUCP (Bdale Garbee) Newsgroups: rec.ham-radio.packet,comp.os.minix,comp.protocols.tcp-ip Subject: KA9Q TCP/IP bits via BBS Message-ID: <89@winfree.UUCP> Date: Thu, 10-Sep-87 01:59:48 EDT Article-I.D.: winfree.89 Posted: Thu Sep 10 01:59:48 1987 Date-Received: Sat, 12-Sep-87 06:39:59 EDT Reply-To: bdale@winfree.UUCP (Bdale Garbee) Organization: Bdale's Berkeley Box, Colorado Springs Lines: 14 I am pleased to report that through the generosity of a local PC dealer, my BBS is back online running a slightly damaged ST-238. The KA9Q TCP/IP package distribution of 870829.0 is now available there for those of you without any other means of obtaining it. As a reminder, the bbs can be reached at 303/593-0766, 300/1200/2400 baud, and first time callers have sufficient privs to download the entire release. Have fun! -- Bdale Garbee, N3EUA phone: 303/593-9828 h, 303/590-2868 w uucp: {bellcore,crash,hp-lsd,ncc,pitt,usafa,vixie}!winfree!bdale arpa: bdale%winfree.uucp@bellcore.com fido: sysop of 128/19 packet: n3eua @ k0hoa, Colorado Springs ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709101018.AA01915@tcgould.TN.CORNELL.EDU] <1987091002262800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: swb@TCGOULD.TN.CORNELL.EDU (Scott Brim) Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP Message-ID: <8709101018.AA01915@tcgould.TN.CORNELL.EDU> Date: Thu, 10-Sep-87 06:26:28 EDT Article-I.D.: tcgould.8709101018.AA01915 Posted: Thu Sep 10 06:26:28 1987 Date-Received: Sat, 12-Sep-87 06:50:29 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 3 LiXia has said that she believes the DEC congestion bit approach is too simple for the real world. Is she available for comment? Scott ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091002350100> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Thu 10 Sep 87 06:23:03-PDT To: "Jonathan P. Biggar" cc: tcp-ip@SRI-NIC.ARPA, brescia@PARK-STREET.BBN.COM Subject: Re: Question about IP options In-reply-to: Your message of Wed, 09 Sep 87 16:42:28 -0700. <8709092342.AA03527@PHOEBE.CAM.UNISYS.COM> Date: Thu, 10 Sep 87 09:15:01 -0400 From: Mike Brescia ... not clearly answered in either RFC 791 or MIL-SPEC 1777: 1) Are the record route and timestamp options modified by the source and destination systems, or are they only modified by gateways? A clear recommendation that hosts implement them would help. You could make use of the information provided by the source host such as 'which interface was used to actually send the packet', and the destination host 'what time was the packet received'. 2) When using either loose or strict source routing, does the next hop or the final destination go in the destination address field of the IP header? Next hop. A rationale for this choice, based on processing power needed, is that a gateway does not have to look at the options unless the IP destination address is the gateway. Then you look for options, and, finding a source route, send it back out again. 3) Is it legal to have both loose and strict source routing options in the same IP packet? If so, how do you handle this case? Legal? Since it's not forbidden, I guess so. What path would a host program expect such a packet to trace? How more useful is it than just one option? Think what the gateway must do if both are present; process the first? do the second if the first is counted out? do the first and ignore the second? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091002382900> Received: from CC5.BBN.COM by SRI-NIC.ARPA with TCP; Thu 10 Sep 87 06:30:48-PDT To: CERF@A.ISI.EDU cc: malis@CC5.BBN.COM, tsuchiya@GATEWAY.MITRE.ORG, schoff@NIC.NYSER.NET, hagens%janeb.spool.wisc.edu@GREMLIN.NRTC.NORTHROP.COM, iso@NRTC.NORTHROP.COM, murayama@CS.UCL.AC.UK, tcp-ip@SRI-NIC.ARPA, malis@CC5.BBN.COM Subject: Re: ISO8473 vs. IP In-reply-to: Your message of 09 Sep 87 22:51:00 -0400. <[A.ISI.EDU] 9-Sep-87 22:51:58.CERF> Date: Thu, 10 Sep 87 09:18:29 -0400 From: Andy Malis Vint, Thanks much. I just got hold of "A Timeout-Based Congestion Control Scheme for Window Flow-Controlled Networks," by Raj Jain of DEC (IEEE J. on Selected Areas in Communications, Vol. SAC-4, no. 7, Oct. 86). It discusses many of these issues, and suggests an algorithm to adjust window sizes based upon congestion indications, although it uses retransmission timeouts to provide the congestion indication rather than a congestion bit in the packet header. Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709101329.AA01481@ucbvax.Berkeley.EDU] <1987091005301200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@PARK-STREET.BBN.COM (Mike Brescia) Newsgroups: comp.protocols.tcp-ip Subject: Re: Question about IP options Message-ID: <8709101329.AA01481@ucbvax.Berkeley.EDU> Date: Thu, 10-Sep-87 09:30:12 EDT Article-I.D.: ucbvax.8709101329.AA01481 Posted: Thu Sep 10 09:30:12 1987 Date-Received: Sat, 12-Sep-87 07:34:44 EDT References: <8709092342.AA03527@PHOEBE.CAM.UNISYS.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 27 ... not clearly answered in either RFC 791 or MIL-SPEC 1777: 1) Are the record route and timestamp options modified by the source and destination systems, or are they only modified by gateways? A clear recommendation that hosts implement them would help. You could make use of the information provided by the source host such as 'which interface was used to actually send the packet', and the destination host 'what time was the packet received'. 2) When using either loose or strict source routing, does the next hop or the final destination go in the destination address field of the IP header? Next hop. A rationale for this choice, based on processing power needed, is that a gateway does not have to look at the options unless the IP destination address is the gateway. Then you look for options, and, finding a source route, send it back out again. 3) Is it legal to have both loose and strict source routing options in the same IP packet? If so, how do you handle this case? Legal? Since it's not forbidden, I guess so. What path would a host program expect such a packet to trace? How more useful is it than just one option? Think what the gateway must do if both are present; process the first? do the second if the first is counted out? do the first and ignore the second? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709101346.AA01657@ucbvax.Berkeley.EDU] <1987091005473600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: malis@CC5.BBN.COM (Andy Malis) Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP Message-ID: <8709101346.AA01657@ucbvax.Berkeley.EDU> Date: Thu, 10-Sep-87 09:47:36 EDT Article-I.D.: ucbvax.8709101346.AA01657 Posted: Thu Sep 10 09:47:36 1987 Date-Received: Sat, 12-Sep-87 07:40:58 EDT References: <[A.ISI.EDU].9-Sep-87.22:51:58.CERF> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Vint, Thanks much. I just got hold of "A Timeout-Based Congestion Control Scheme for Window Flow-Controlled Networks," by Raj Jain of DEC (IEEE J. on Selected Areas in Communications, Vol. SAC-4, no. 7, Oct. 86). It discusses many of these issues, and suggests an algorithm to adjust window sizes based upon congestion indications, although it uses retransmission timeouts to provide the congestion indication rather than a congestion bit in the packet header. Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709101459.AA02489@ucbvax.Berkeley.EDU] <1987091006135000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: TS0400@OHSTVMA.BITNET (Bob Dixon) Newsgroups: comp.protocols.tcp-ip Subject: Re: Advanced Computer Communication's Access Product for MVS Message-ID: <8709101459.AA02489@ucbvax.Berkeley.EDU> Date: Thu, 10-Sep-87 10:13:50 EDT Article-I.D.: ucbvax.8709101459.AA02489 Posted: Thu Sep 10 10:13:50 1987 Date-Received: Sat, 12-Sep-87 08:49:20 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 We have an ACC system running on our MVS system (3081D). It basically works fine, and is very fast, although some of the speed impression may be caused by the high speed of the 3081. We use UCLA mail to front-end smtp. That causes minor problems as UCLA mail does not allow the full smtp address syntax. Full-screen telnet to a VM system running KNET does not work. Line-mode telnet works fine. FTP is very powerful in dealing with MVS files, but requires the user to supply the MVS volume name, which is a pain. FTP allows file transfer between any 2 computers, neither of which needs to be the MVS system. This is useful, but requires the user to provide login info for MVS twice if one of the systems is MVS. Bob Dixon Ohio State University Acknowledge-To: ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091006135001> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Thu 10 Sep 87 07:41:28-PDT Received: from OHSTVMA.BITNET by wiscvm.wisc.edu ; Thu, 10 Sep 87 09:41:28 CDT Received: by OHSTVMA (Mailer X1.23b) id 3996; Thu, 10 Sep 87 10:33:39 EDT Date: Thu, 10 Sep 87 10:13:50 EDT From: Bob Dixon Subject: Re: Advanced Computer Communication's Access Product for MVS To: TCP-IP@SRI-NIC.ARPA In-Reply-To: Your message of 9 Sep 87 19:09:37 GMT We have an ACC system running on our MVS system (3081D). It basically works fine, and is very fast, although some of the speed impression may be caused by the high speed of the 3081. We use UCLA mail to front-end smtp. That causes minor problems as UCLA mail does not allow the full smtp address syntax. Full-screen telnet to a VM system running KNET does not work. Line-mode telnet works fine. FTP is very powerful in dealing with MVS files, but requires the user to supply the MVS volume name, which is a pain. FTP allows file transfer between any 2 computers, neither of which needs to be the MVS system. This is useful, but requires the user to provide login info for MVS twice if one of the systems is MVS. Bob Dixon Ohio State University Acknowledge-To: ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709101444.AA02305@ucbvax.Berkeley.EDU] <1987091006320800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) Newsgroups: comp.protocols.tcp-ip Subject: Re: Multiple 331 password responses in FTP protocol Message-ID: <8709101444.AA02305@ucbvax.Berkeley.EDU> Date: Thu, 10-Sep-87 10:32:08 EDT Article-I.D.: ucbvax.8709101444.AA02305 Posted: Thu Sep 10 10:32:08 1987 Date-Received: Sat, 12-Sep-87 08:48:54 EDT References: <090987.094643.PERSHNG@ibm.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 43 As one of the perpetrators of FTP--and, indeed, one of the primary perpetrators of the PASS command: cf. RFC 491--it might be appropriate for me to assure you that I do understand the necessity of periodic password changes. I even understood it in 1972/3, when I was perpetrating. However, I neither understand nor stipulate that the abstract necessity for accomplishing the action dictates a concrete necessity for so doing under the explicit cognizance of FTP, to this day. N.B., I said "explicit"; that is, if a given Server wants to make the function available via FTP and can come up with a syntax such that the User FTP implementations "all" think it's just a normal password being sent through them (say, use "\\\" as the separator, or some single character that isn't licit in the Server's passwords, or any trick that avoids there being a space in the line, since User FTPs shouldn't boggle at the length of a password but might well be doing next-non-blank parsing), there doesn't seem to be a (protocol) problem. Unless, of course, too many User FTPs don't implement my conviction that they can't possibly assume they know the length of a password, but that's a different problem.... Actually, I could side with an argument which held that User FTPs "should" be sending along everything input to them from whatever their local indications that a PASS comand is wanted are through to whatever their local indications that the command/line is ended are, if anybody wants to raise it. But I think the issue which should dominate is that a Server is within its "rights" to play games with the interpretations of given variables' internal syntax as long as the variables are sent correctly according to the protocol's gross syntax, so the above-sketched trick should work regardless-- provided I'm not overlooking any contrary-to-our-design-intent glitches which might have been introduced into the spec with regard to limitations on the length of the password string. If I have to, I'll dig out the spec from my piling system later; for now, though, I think I'll settle for casting my metaphorical vote in favor of having the ACCESS/MVS (or however they spell it) Server FTP simply treat the outdated password as the incorrect password that it in essence is and include text in the appropriate error message explaining what syntax they want used in a subsequent PASS command's argument field to make things right. After all, we wanted to make FTP "usable by automata" at the outset, but we never were so fanatic about it that we explicitly banned touching by human hands, as I recall. cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091006320801> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Thu 10 Sep 87 07:39:41-PDT Date: 10 Sep 1987 10:32:08 EDT Subject: Re: Multiple 331 password responses in FTP protocol From: Michael Padlipsky To: John Pershing cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: <090987.094643.PERSHNG@ibm.com> As one of the perpetrators of FTP--and, indeed, one of the primary perpetrators of the PASS command: cf. RFC 491--it might be appropriate for me to assure you that I do understand the necessity of periodic password changes. I even understood it in 1972/3, when I was perpetrating. However, I neither understand nor stipulate that the abstract necessity for accomplishing the action dictates a concrete necessity for so doing under the explicit cognizance of FTP, to this day. N.B., I said "explicit"; that is, if a given Server wants to make the function available via FTP and can come up with a syntax such that the User FTP implementations "all" think it's just a normal password being sent through them (say, use "\\\" as the separator, or some single character that isn't licit in the Server's passwords, or any trick that avoids there being a space in the line, since User FTPs shouldn't boggle at the length of a password but might well be doing next-non-blank parsing), there doesn't seem to be a (protocol) problem. Unless, of course, too many User FTPs don't implement my conviction that they can't possibly assume they know the length of a password, but that's a different problem.... Actually, I could side with an argument which held that User FTPs "should" be sending along everything input to them from whatever their local indications that a PASS comand is wanted are through to whatever their local indications that the command/line is ended are, if anybody wants to raise it. But I think the issue which should dominate is that a Server is within its "rights" to play games with the interpretations of given variables' internal syntax as long as the variables are sent correctly according to the protocol's gross syntax, so the above-sketched trick should work regardless-- provided I'm not overlooking any contrary-to-our-design-intent glitches which might have been introduced into the spec with regard to limitations on the length of the password string. If I have to, I'll dig out the spec from my piling system later; for now, though, I think I'll settle for casting my metaphorical vote in favor of having the ACCESS/MVS (or however they spell it) Server FTP simply treat the outdated password as the incorrect password that it in essence is and include text in the appropriate error message explaining what syntax they want used in a subsequent PASS command's argument field to make things right. After all, we wanted to make FTP "usable by automata" at the outset, but we never were so fanatic about it that we explicitly banned touching by human hands, as I recall. cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709101512.AA02777@ucbvax.Berkeley.EDU] <1987091006383700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: TS0400@OHSTVMA.BITNET (Bob Dixon) Newsgroups: comp.protocols.tcp-ip Subject: Re: Once More on FTP Password Expiration, Etc. Message-ID: <8709101512.AA02777@ucbvax.Berkeley.EDU> Date: Thu, 10-Sep-87 10:38:37 EDT Article-I.D.: ucbvax.8709101512.AA02777 Posted: Thu Sep 10 10:38:37 1987 Date-Received: Sat, 12-Sep-87 08:54:33 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 As another customer, I agree that FTP has no business worrying about expired passwords. Unless I misunderstand what is going on. Bob Dixon Ohio State University Acknowledge-To: ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091006383701> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Thu 10 Sep 87 07:44:27-PDT Received: from OHSTVMA.BITNET by wiscvm.wisc.edu ; Thu, 10 Sep 87 09:44:30 CDT Received: by OHSTVMA (Mailer X1.23b) id 4263; Thu, 10 Sep 87 10:40:45 EDT Date: Thu, 10 Sep 87 10:38:37 EDT From: Bob Dixon Subject: Re: Once More on FTP Password Expiration, Etc. To: TCP-IP@SRI-NIC.ARPA In-Reply-To: Your message of Wed, 9 Sep 87 12:49:11 EDT As another customer, I agree that FTP has no business worrying about expired passwords. Unless I misunderstand what is going on. Bob Dixon Ohio State University Acknowledge-To: ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1748@canisius.UUCP] <1987091007162900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sia@canisius.UUCP (Stewart Alpert @ Ingram Software) Newsgroups: comp.dcom.lans,comp.unix.xenix,comp.sources.wanted,comp.protocols.tcp-ip Subject: Public Domain TCP/IP software Message-ID: <1748@canisius.UUCP> Date: Thu, 10-Sep-87 11:16:29 EDT Article-I.D.: canisius.1748 Posted: Thu Sep 10 11:16:29 1987 Date-Received: Sat, 12-Sep-87 08:45:16 EDT Distribution: na Organization: Canisius College, Buffalo N.Y. 14208 Lines: 2 Keywords: TCP/IP network unix source public domain Could anybody who knows of any public domain implementations of tcp/ip please drop me a line. thanks. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709110451.AA19614@ucbvax.Berkeley.EDU] <1987091007314100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP Message-ID: <8709110451.AA19614@ucbvax.Berkeley.EDU> Date: Thu, 10-Sep-87 11:31:41 EDT Article-I.D.: ucbvax.8709110451.AA19614 Posted: Thu Sep 10 11:31:41 1987 Date-Received: Sat, 12-Sep-87 16:35:13 EDT References: <[A.ISI.EDU].9-Sep-87.22:43:32.CERF> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 49 My initial impulse was to respond to the call for a hose to hose protocol with a private message saying "Nozzle yourself, Vinton: you really shouldn't faucet like that." Then I made the mistake of thinking a bit about what hose to hose protocols would actually be like, and I realized that there's a fairly powerful metaphor lurking there. Think about it: if you have two garden hoses, all you need is a suitably threaded (presumably "female-female") adaptor, even if the threads on each of the hoses "aren't standard". The worst that would happen is that you'd discover nobody made appropriate adaptors and it would be cheaper to buy a longer hose (which, with any luck at all, was thread compatible with the faucet) than to have someone fabricate the special widget. (Please recall I've always spoken well of physical standards, b/t/w.) But if you want to couple a fire hose and a garden hose, you'd need to call in a fluid dynamicist to calculate how long the taper had to be so as not to lead to bursting the garden hose and then go in for some serious metalwork to get the adaptor built. (Not a job for the village smithy [they shoe horses, don't they?], I'd imagine.) And if you wanted to go beyond the conventional Gateway problem, consider the Translating/Mapping Gateway analogue, where some of the time what you need is to couple a hose designed for carrying liquid oxygen with a hose designed for carrying water to your lawn: by the time you put enough heat into the adaptor so the garden hose doesn't shatter from the cold, you've probably lost sight of the fact that your lawn doesn't really need oxygen in the first place. Other permutations on the theme are doubtless available, and even relevant, but can safely be left as an exercise.... cheers, map P.S. At the risk of violating tradition and linking this back up to the question which started it all, one way of viewing the difference between ISO IP and ARPANET IP is that each is supposed to be threaded to a different faucet. But, then, another way of viewing the difference is to think about the news item I heard over the weekend, where some builder in one of the cities the Pope is visiting had donated several of his houses for the lodging of the papal entourage, since he believed they'd be worth more later because he had heard that the Pope blessed every house he entered (not clear that the Pope would enter every house, of course, but then I've never claimed to be up on ad man logic): so to change the metaphor from the lawn to the house, they do have slightly different floor plans, they both serve the same fundamental purpose of being boxes to stay out of the weather in, they're in the same neighborhood and all, but this one's gonna cost ya $25,000 more because It's Been Papally Blessed! ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091007314101> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Thu 10 Sep 87 08:35:38-PDT Date: 10 Sep 1987 11:31:41 EDT Subject: Re: ISO8473 vs. IP From: Michael Padlipsky To: CERF@A.ISI.EDU cc: schoff@NIC.NYSER.NET, Mills@LOUIE.UDEL.EDU, iso@NRTC.NORTHROP.COM, murayama@CS.UCL.AC.UK, tcp-ip@SRI-NIC.ARPA In-Reply-To: <[A.ISI.EDU] 9-Sep-87 22:43:32.CERF> My initial impulse was to respond to the call for a hose to hose protocol with a private message saying "Nozzle yourself, Vinton: you really shouldn't faucet like that." Then I made the mistake of thinking a bit about what hose to hose protocols would actually be like, and I realized that there's a fairly powerful metaphor lurking there. Think about it: if you have two garden hoses, all you need is a suitably threaded (presumably "female-female") adaptor, even if the threads on each of the hoses "aren't standard". The worst that would happen is that you'd discover nobody made appropriate adaptors and it would be cheaper to buy a longer hose (which, with any luck at all, was thread compatible with the faucet) than to have someone fabricate the special widget. (Please recall I've always spoken well of physical standards, b/t/w.) But if you want to couple a fire hose and a garden hose, you'd need to call in a fluid dynamicist to calculate how long the taper had to be so as not to lead to bursting the garden hose and then go in for some serious metalwork to get the adaptor built. (Not a job for the village smithy [they shoe horses, don't they?], I'd imagine.) And if you wanted to go beyond the conventional Gateway problem, consider the Translating/Mapping Gateway analogue, where some of the time what you need is to couple a hose designed for carrying liquid oxygen with a hose designed for carrying water to your lawn: by the time you put enough heat into the adaptor so the garden hose doesn't shatter from the cold, you've probably lost sight of the fact that your lawn doesn't really need oxygen in the first place. Other permutations on the theme are doubtless available, and even relevant, but can safely be left as an exercise.... cheers, map P.S. At the risk of violating tradition and linking this back up to the question which started it all, one way of viewing the difference between ISO IP and ARPANET IP is that each is supposed to be threaded to a different faucet. But, then, another way of viewing the difference is to think about the news item I heard over the weekend, where some builder in one of the cities the Pope is visiting had donated several of his houses for the lodging of the papal entourage, since he believed they'd be worth more later because he had heard that the Pope blessed every house he entered (not clear that the Pope would enter every house, of course, but then I've never claimed to be up on ad man logic): so to change the metaphor from the lawn to the house, they do have slightly different floor plans, they both serve the same fundamental purpose of being boxes to stay out of the weather in, they're in the same neighborhood and all, but this one's gonna cost ya $25,000 more because It's Been Papally Blessed! ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709101653.AA24571@p.cs.uiuc.edu] <1987091008530600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gillies@P.CS.UIUC.EDU (Don Gillies) Newsgroups: comp.protocols.tcp-ip Subject: DL removal Message-ID: <8709101653.AA24571@p.cs.uiuc.edu> Date: Thu, 10-Sep-87 12:53:06 EDT Article-I.D.: p.8709101653.AA24571 Posted: Thu Sep 10 12:53:06 1987 Date-Received: Sat, 12-Sep-87 09:41:57 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 2 please take me off your distribution list. Thanks. Don ., ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091013062800> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Thu 10 Sep 87 07:05:17-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA01835; Thu, 10 Sep 87 07:01:41 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: 10 Sep 87 13:06:28 GMT From: caip.rutgers.edu!keilp@RUTGERS.EDU (Carol Keilp) Organization: Rutgers Univ., New Brunswick, N.J. Subject: remove from mailing list Message-Id: <4360@caip.rutgers.edu> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa Please remove me from the mailing list. Thank you. Keilp@caip.rutgers.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [582@houxv.UUCP] <1987091013252600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rdt@houxv.UUCP Newsgroups: comp.protocols.tcp-ip Subject: need x.25 multibus2 board recommendation Message-ID: <582@houxv.UUCP> Date: Thu, 10-Sep-87 17:25:26 EDT Article-I.D.: houxv.582 Posted: Thu Sep 10 17:25:26 1987 Date-Received: Sat, 12-Sep-87 15:04:25 EDT Organization: ATT Information Systems, Holmdel, N.J. Lines: 15 Keywords: on-board tcpip and/or x.25 packet layer firmware plus layer2 I need a recommendation for selecting a multibus2 X.25 card with onboard firmware to do either tcpip and/or x.25 plp processing (as in BX.25). Could anyone give me the benifit of their experience? Please include the name of the manufacturer, model, conformance with standards and the difficulty of porting client packages. I am only familiar with the att 3b/isc card which is not designed for a multibus2 form factor. Richard Trauben ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709102353.AA14513@ucbvax.Berkeley.EDU] <1987091015394800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: comp.protocols.tcp-ip Subject: [VWHITE@NSWC-G.ARPA:] Message-ID: <8709102353.AA14513@ucbvax.Berkeley.EDU> Date: Thu, 10-Sep-87 19:39:48 EDT Article-I.D.: ucbvax.8709102353.AA14513 Posted: Thu Sep 10 19:39:48 1987 Date-Received: Sat, 12-Sep-87 11:20:37 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 107 I'm forwarding this to this list because I think most of the answers can come from it. These people are building themselves a marvelous environment and are looking for the superglue. Of course, not one brand of superglue exists to solve it all, but I think the components are present here. Each one contribute one idea and we can build them a viable internet. Thanks, Dan --------------- Return-Path: <@wiscvm.wisc.edu:BIG-LAN@SUVM.BITNET> Received: FROM WISCVM.WISC.EDU BY USC-ISIA.ARPA WITH TCP ; 10 Sep 87 18:39:54 EDT Received: from SUVM.BITNET by wiscvm.wisc.edu ; Thu, 10 Sep 87 11:39:07 CDT Received: by SUVM (Mailer X1.25) id 5087; Thu, 10 Sep 87 11:19:29 LCL Date: Thu, 10 Sep 87 09:48:19 edt Reply-To: Campus-Size LAN Discussion Group Sender: Campus-Size LAN Discussion Group Comments: Resent-Date: Thu, 10 Sep 1987 11:16:00 LCL Comments: Resent-From: John M. Wobus X-To: Campus LAN Discussion Group , BIG-LAN%SUVM.BITNET@WISCVM.WISC.EDU From: VWHITE@NSWC-G.ARPA To: "Kevin M. Leahy" , Dan Lynch Request for Information 10 September 1987 We are currently investigating methods of providing networked services to PC users at a large government installation and would appreciate any leads anyone could give us. BACKGROUND: The user community may eventually number 2000-3000 persons using IBM compatible PCs primarily for word processing, spreadsheet, and database applications (WordPerfect, Lotus, and DBASE). We must allow these users to share files, printers, and other resources and to exchange mail with one another and across the MILNET. These users are located in multiple buildings at two geographic sites separated by over 50 miles. We have a large base of installed minicomputers (VAXen, CCI Power 6, Pyramid, Sun) which run Unix (4.1c, 4.2, Ultrix, Pyramid's OSX) and which we want to reuse to the greatest extent possible as servers for the PCs. These minicomputers are connected via an 802.3 baseband network using the DoD TCP/IP protocols; the two geographic sites are connected via a T1 microwave link. Required capabilities include: Transparent file service. The user should be able to access the server's disk as if it were a hard drive on on the workstation. Telnet and ftp-type applications are welcome, but alone are not sufficient. Transparent print service. At the least, the user should be able to send documents from his PC to a shared printer with a simple command. It would be nice if all his applications (WordPerfect, DBase) could do the same thing. A mail service which receives and stores the user's mail even if the PC is not online, allows the user to read his mail from his PC, and uses or can interface to smtp mail. Acceptable solutions must adhere to IEEE 802.3 and must use the DoD TCP/IP protocols or provide gateway services to a TCP/IP network. They don't have to work with Macintoshes, but that would be an added plus. We have looked or are now looking at Novell NetWare, the IBM PC Network, 3Com 3+Share, Sun NFS, Locus PC Interface, Syntax SMBserver, and several public domain packages (CMU PCTCP, CMU Repository Mailer, Phil Karn's KA9Q PCTCP). REQUEST FOR INFO: Has anybody out there solved a similar problem? If so, what did you use and how would you rate your solution? Does anybody have a lead on a product not in the list above which would meet all or most of our criteria? How important is NetBIOS compatibility? From what we've seen, nobody as yet is adhering to the RFCs from the NetBIOS over TCP Working Group. We are also concerned about the advent of OS/2 and the LAN Manager and what that will mean to NetBIOS. Is NetBIOS an emerging/existing standard for PC networking, or will it go away? Thanks for any help you can offer. vwhite@nswc-g.arpa Vicky White Code K33 NSWC Dahlgren, VA 22448 (703) 663-7745 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091015394801> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Thu 10 Sep 87 16:44:56-PDT Date: 10 Sep 1987 19:39:48 EDT Subject: [VWHITE@NSWC-G.ARPA:] From: Dan Lynch To: tcp-ip@SRI-NIC.ARPA cc: lynch@A.ISI.EDU, vwhite@NSWC-G.ARPA I'm forwarding this to this list because I think most of the answers can come from it. These people are building themselves a marvelous environment and are looking for the superglue. Of course, not one brand of superglue exists to solve it all, but I think the components are present here. Each one contribute one idea and we can build them a viable internet. Thanks, Dan --------------- Return-Path: <@wiscvm.wisc.edu:BIG-LAN@SUVM.BITNET> Received: FROM WISCVM.WISC.EDU BY USC-ISIA.ARPA WITH TCP ; 10 Sep 87 18:39:54 EDT Received: from SUVM.BITNET by wiscvm.wisc.edu ; Thu, 10 Sep 87 11:39:07 CDT Received: by SUVM (Mailer X1.25) id 5087; Thu, 10 Sep 87 11:19:29 LCL Date: Thu, 10 Sep 87 09:48:19 edt Reply-To: Campus-Size LAN Discussion Group Sender: Campus-Size LAN Discussion Group Comments: Resent-Date: Thu, 10 Sep 1987 11:16:00 LCL Comments: Resent-From: John M. Wobus X-To: Campus LAN Discussion Group , BIG-LAN%SUVM.BITNET@WISCVM.WISC.EDU From: VWHITE@NSWC-G.ARPA To: "Kevin M. Leahy" , Dan Lynch Request for Information 10 September 1987 We are currently investigating methods of providing networked services to PC users at a large government installation and would appreciate any leads anyone could give us. BACKGROUND: The user community may eventually number 2000-3000 persons using IBM compatible PCs primarily for word processing, spreadsheet, and database applications (WordPerfect, Lotus, and DBASE). We must allow these users to share files, printers, and other resources and to exchange mail with one another and across the MILNET. These users are located in multiple buildings at two geographic sites separated by over 50 miles. We have a large base of installed minicomputers (VAXen, CCI Power 6, Pyramid, Sun) which run Unix (4.1c, 4.2, Ultrix, Pyramid's OSX) and which we want to reuse to the greatest extent possible as servers for the PCs. These minicomputers are connected via an 802.3 baseband network using the DoD TCP/IP protocols; the two geographic sites are connected via a T1 microwave link. Required capabilities include: Transparent file service. The user should be able to access the server's disk as if it were a hard drive on on the workstation. Telnet and ftp-type applications are welcome, but alone are not sufficient. Transparent print service. At the least, the user should be able to send documents from his PC to a shared printer with a simple command. It would be nice if all his applications (WordPerfect, DBase) could do the same thing. A mail service which receives and stores the user's mail even if the PC is not online, allows the user to read his mail from his PC, and uses or can interface to smtp mail. Acceptable solutions must adhere to IEEE 802.3 and must use the DoD TCP/IP protocols or provide gateway services to a TCP/IP network. They don't have to work with Macintoshes, but that would be an added plus. We have looked or are now looking at Novell NetWare, the IBM PC Network, 3Com 3+Share, Sun NFS, Locus PC Interface, Syntax SMBserver, and several public domain packages (CMU PCTCP, CMU Repository Mailer, Phil Karn's KA9Q PCTCP). REQUEST FOR INFO: Has anybody out there solved a similar problem? If so, what did you use and how would you rate your solution? Does anybody have a lead on a product not in the list above which would meet all or most of our criteria? How important is NetBIOS compatibility? From what we've seen, nobody as yet is adhering to the RFCs from the NetBIOS over TCP Working Group. We are also concerned about the advent of OS/2 and the LAN Manager and what that will mean to NetBIOS. Is NetBIOS an emerging/existing standard for PC networking, or will it go away? Thanks for any help you can offer. vwhite@nswc-g.arpa Vicky White Code K33 NSWC Dahlgren, VA 22448 (703) 663-7745  ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091103354800> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Fri 11 Sep 87 03:01:52-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA23609; Fri, 11 Sep 87 02:40:49 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: 11 Sep 87 03:35:48 GMT From: nysernic!itsgw!steinmetz!uunet!quick!srg@RUTGERS.EDU (Spencer Garrett) Organization: Quicksilver Engineering, Seattle Subject: Assigning ethernet numbers Message-Id: <113@quick.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa Can anyone tell me where to go to get a block of ethernet hardware addresses for my company? We're going to be making terminal servers, so we do need to assign these numbers to our products. Thanks. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709111413.AA04439@etn-wlv.eaton.com] <1987091106134700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) Newsgroups: comp.protocols.tcp-ip Subject: Re: [VWHITE@NSWC-G.ARPA:] Message-ID: <8709111413.AA04439@etn-wlv.eaton.com> Date: Fri, 11-Sep-87 10:13:47 EDT Article-I.D.: etn-wlv.8709111413.AA04439 Posted: Fri Sep 11 10:13:47 1987 Date-Received: Sat, 12-Sep-87 17:40:08 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 51 Vicky, Dan, et. al.: If you can get access to the Request For Proposal (RFP) and the vendor propos- als for LONS, RAPIDE, UTAIN/MAIS, and ULANA; you may find some of the answers to the questions that you have raised. LONS and its predecessor LONEX (Local Office Network Experiment) are probably more in line with what you want to do. LONEX has been operational since the early 80's at Rome Air Development Center (RADC), Griffiss AFB and has links to and facilities at Hanscom Field and Wright-Patterson AFB. This message is being generated from home on a Tandy 2000 linked to the LONEX development and maintenance network at EATON IMSD in Westlake Village, CA which is also linked into RADC-LONEX.ARPA. LONEX was originally designed for a broadband with dedicated links to Hanscom and Wright-Patterson; however, the broadband has been replaced with Ethernet and the dedicated links are being replaced by the MILNET. The original plan was to support a large number of users using VT100 or VT100 compatible term- inals; however, that is also changing with many of the organisations using LONEX replacing them with PC's. PC's are not as fully integrated as you would like and generally use terminal emulation packages to interface with the network. I, personally, use the Softronic's SoftermPC package on which I have implemented a seamless disk capability so that disks on the network look like local hard disks to my PC. I can tell you from experience it can be painful--applications developed for MS-DOS choke if you have to use UNIX pathnames to get to your data. For some silly reason they attempt to parse switches whenever they see a "/". Anyway, the LONEX system runs on anything that can run on any processor that supports 2.9bsd or 4.3bsd. It goes "boom" on System Vanilla. It supports several of the more popular spreadsheet programs and databases and depending on the size of your spreadsheets moves the processing to more appropriate machines. Users in essence always execute from their home processor regard- less of where they may be and for the most part its transparent to the user. If you normally work at Hanscom but are temporarily at Wright Patterson, you may notice some latency. (This feature is probably the biggest reason why there hasn't been a stronger hue and cry for more fully integrating PCs into the system. As long as you can get to a TAC, you can work on your reports from anywhere in the world. You don't have to lug the PC along and if you're forced to fly commercial, you avoid the hassle at customs where they try to extract the import duties on your PC). Enough this. Request a tour and briefing from RADC to determine if it is useful and to find the pitfalls. Merton Campbell Crockett mcc@etn-wlv.eaton.com AN/GYQ-21(V) Program mcc%lonex@etn-wlv.eaton.com EATON Information Management Systems 31717 La Tienda Drive, Box 5009 Westlake Village, CA 91539 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [WANCHO.12333796945.BABYL@SIMTEL20.ARPA] <1987091108500000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: WANCHO@SIMTEL20.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Can of worms... Message-ID: Date: Fri, 11-Sep-87 12:50:00 EDT Article-I.D.: SIMTEL20.WANCHO.12333796945.BABYL Posted: Fri Sep 11 12:50:00 1987 Date-Received: Sat, 12-Sep-87 18:08:43 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 50 The following message opens up an extremely touchy subject on this forum. I am bringing it up here because I am looking for a relatively "easy-to-implement" alternate *technical* solution to the problem which will work in the present TCP/IP environment and in the future ISO environment. The Communications Services Industrial Fund (CSIF) of DCA has been tasked to implement a usage-sensitive chargeback only for hosts connected to the MILNET backbone in the very near future. The problem is that the method chosen is probably the easiest to implement in that only PSN code is involved and no host code changes are required. However, it is the least equitable: simply charge each host for all the traffic it originates and all traffic in both directions from a TAC port. The host is also charged for connect time on dialup TAC ports. No such chargeback is being planned for ARPANET hosts. When this scheme is in place, we will probably have to drop our popular services, such as hosting large mailing lists, ANONYMOUS FTP access to our very large public domain collections, and TAC access by our regular users. With no reason to remain directly connected to the MILNET backbone, we will then move our connection to the other side of our gateway to further reduce costs. Given the cost figures based on our current traffic, (heresy follows:) it might even be more economical to extend our own net using high-speed dialup ala USENET, BITNET, etc... However, it might be possible to create a fair, and therefore, tolerable, chargeback algorithm. It requires a further extension to the AHIP-E protocol and possibly only "trivial" changes to certain host software. To make things equitable, charge the host for all traffic it generates in BOTH directions of a connection it originates. However, (here's the hard part) allow for "collect call" connections to be made and not accumulate charges until the remote host has accepted the call. It seems that part of this mechanism already exists for MILNET TACs in that all traffic is to be charged to each connected host on a connection by connection basis. This alternative would seem to take care of the large mailing list problem in that those messages would be sent collect. ANONYMOUS FTP connections would be charged to the calling host. That leaves TAC access. It would be more economical to open up and add more direct-dial ports to our systems, or put TACs on the other side of gateway hosts, than allow TAC dialup access from a MILNET TAC port. OK, given all that, the only real questions I have for this list are: is it possible to extend the AHIP-E protocol to allow for a collect call to be passed to the remote host, and what would it take to get it implemented and tested in the next year or so? --Frank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709111721.AA01329@decwrl.dec.com] <1987091111140000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jain@erlang.DEC.COM (Raj Jain, LKG 1-2/A19 DTN: 226-7642) Newsgroups: comp.protocols.tcp-ip Subject: ISO 8473 vs IP (Congestion experienced bit) Message-ID: <8709111721.AA01329@decwrl.dec.com> Date: Fri, 11-Sep-87 15:14:00 EDT Article-I.D.: decwrl.8709111721.AA01329 Posted: Fri Sep 11 15:14:00 1987 Date-Received: Sat, 12-Sep-87 18:09:57 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 We have a hot-off-the-press DEC Technical Report DEC-TR-506 which summarizes our work on congestion avoidance and explains the merits of the 'congestion experienced' bit in ISO 8473. Title: CONGESTION AVOIDANCE IN COMPUTER NETWORKS WITH A CONNECTIONLESS NETWORK LAYER Authors: Raj Jain, K. K. Ramakrishnan, Dah-Ming Chiu Digital Equipment Corp. Littleton, MA 01460 Date: August 1987. If you would like a copy of the report mailed to you, please send me your U.S. Mail address. My network address on ARPAnet is Jain%Erlang.dec@decwrl.dec.com Also, we would presenting the scheme in detail at the next NBS/OSI implementors workshop in october. -Raj ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2772@bobkat.UUCP] <1987091111271600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: vik@bobkat.UUCP (Vik Ram Sohal) Newsgroups: comp.dcom.lans,comp.unix.xenix,comp.sources.wanted,comp.protocols.tcp-ip Subject: Re: Public Domain TCP/IP software Message-ID: <2772@bobkat.UUCP> Date: Fri, 11-Sep-87 15:27:16 EDT Article-I.D.: bobkat.2772 Posted: Fri Sep 11 15:27:16 1987 Date-Received: Sun, 13-Sep-87 10:49:38 EDT References: <1748@canisius.UUCP> Reply-To: vik@bobkat.UUCP (Vik Sohal) Distribution: na Organization: Digital Lynx, Inc; Dallas, TX Lines: 6 Keywords: TCP/IP network unix source public domain I would appreciate any info on getting TCP/IP source as well!!! Vik End Of Line... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [558387616.0.PERRY@VAX.DARPA.MIL] <1987091111401500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL (Dennis G. Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: [VWHITE@NSWC-G.ARPA:] Message-ID: <558387616.0.PERRY@VAX.DARPA.MIL> Date: Fri, 11-Sep-87 15:40:15 EDT Article-I.D.: VAX.558387616.0.PERRY Posted: Fri Sep 11 15:40:15 1987 Date-Received: Sat, 12-Sep-87 19:19:54 EDT References: <8709111413.AA04439@etn-wlv.eaton.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 My understanding from the folks at RADC is the LONEX is going away, an no further enhancements are allowed to the system. I wonder what they are moving to? dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709112213.aa23967@Huey.UDEL.EDU] <1987091118130700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: EGP updates over the top Message-ID: <8709112213.aa23967@Huey.UDEL.EDU> Date: Fri, 11-Sep-87 22:13:07 EDT Article-I.D.: Huey.8709112213.aa23967 Posted: Fri Sep 11 22:13:07 1987 Date-Received: Sat, 12-Sep-87 22:33:46 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Folks, EGP jumbograms observed here have topped out above the ARPANET MTU of 1006+ octets, which means they will be fragmented. I'm sure the many Unix system wizards will be casting spells on the reassembly buffer size and crank that up accordingly. For the fuzzball system warlocks, be advised its EGP does now reassemble updates. Fixes will be distributed over the weekend. The reason I dropped this message on the full list is an interesting observation that the LSI-11 core gateways set the don't-fragment bit on updates to match the same bit on received packets. Thus, if your EGP code sets this bit in the IP header, the update that comes back will self-destruct while coming back. Obviously, the don't-fragment bit should not be set. having flattened head while learning the above nugget today, I would like to invite our BBN comrades to expand upon the theme. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709120454.AA01431@columbia-pdn] <1987091120540400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rms@columbia-pdn (Ron Stoughton acc_gnsc) Newsgroups: comp.protocols.tcp-ip Subject: ACC Customer Service Message-ID: <8709120454.AA01431@columbia-pdn> Date: Sat, 12-Sep-87 00:54:04 EDT Article-I.D.: columbia.8709120454.AA01431 Posted: Sat Sep 12 00:54:04 1987 Date-Received: Sun, 13-Sep-87 06:20:27 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Howard, ACC Customer Service can be reached at service@acc-sb-unix.arpa. If that doesn't work, please let me know. Ron Stoughton rms@acc-sb-unix.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709121419.AA21794@ucbvax.Berkeley.EDU] <1987091206195900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: zwang@CS.UCL.AC.UK (Zheng Wang) Newsgroups: comp.protocols.tcp-ip Subject: IP Options Message-ID: <8709121419.AA21794@ucbvax.Berkeley.EDU> Date: Sat, 12-Sep-87 10:19:59 EDT Article-I.D.: ucbvax.8709121419.AA21794 Posted: Sat Sep 12 10:19:59 1987 Date-Received: Sun, 13-Sep-87 09:39:10 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 What will happen if a packet with a source route option goes through a unix 4.2 gateway ? Will the gateway strip the option out after updating ? Zheng. zwang@uk.ac.ucl.cc ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709122146.AA05786@etn-wlv.eaton.com] <1987091213462400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mcc@ETN-WLV.EATON.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: [VWHITE@NSWC-G.ARPA:] Message-ID: <8709122146.AA05786@etn-wlv.eaton.com> Date: Sat, 12-Sep-87 17:46:24 EDT Article-I.D.: etn-wlv.8709122146.AA05786 Posted: Sat Sep 12 17:46:24 1987 Date-Received: Sun, 13-Sep-87 08:52:54 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 22 Dennis: The operational system to replace the experimental system is LONS and that is the official line; however, I think there is a great deal of resistance at the LONEX user level. I'm not sure what the final configuration of LONS is going to be; however, one component seems to be a single VAX system that provides the same user services provided by the array of PDP11/44, PDP11/70, and VAX systems used ithe LONEX system. While LONS is the "official" system, I doubt that LONEX will disappear in the near future. You have a large group of users that are familiar with the facilities of LONEX. Experience at EATON indicates that it is very easy to move secretaries whose primary use of the system to prepare letters and mem- orandae from one system to another but it is quite another to move people that use a system for preparing technical documentation and proposals part- icularly if these documents are going to be modified and reproduced over a period of time. In essence, the "old" system will not be replaced until a catastrophic event occurs--because no one wants to spend the money to con- vert all the data from the formats required by the "old" system to that re- quited by the "new" system. Merton Campbell Crockett ----MESSAGE-END---- ----MESSAGE-BEGIN---- [558482479.0.PERRY@VAX.DARPA.MIL] <1987091214011800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: [VWHITE@NSWC-G.ARPA:] Message-ID: <558482479.0.PERRY@VAX.DARPA.MIL> Date: Sat, 12-Sep-87 18:01:18 EDT Article-I.D.: VAX.558482479.0.PERRY Posted: Sat Sep 12 18:01:18 1987 Date-Received: Sun, 13-Sep-87 08:53:16 EDT References: <8709122146.AA05786@etn-wlv.eaton.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Merton, I had heard the LONEX was going to go away because I had asked the RADC people to fix lonex so that, at least on there system, mail send to an individual would include who is on the 'cc' line. I wanted to make certain that eveyone involved in the discussion was being copied. Lonex apparently cannot do that. It sends out mail with blank cc lines and I do not know who else got the message, nor can I answer to everyone. If lonex is going to be around, this would be a good thing to fix. The RADC peole say that this would be a major change to the guts of the system and will not be done. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709122259.AA05868@etn-wlv.eaton.com] <1987091214591000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mcc@ETN-WLV.EATON.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: [VWHITE@NSWC-G.ARPA:] Message-ID: <8709122259.AA05868@etn-wlv.eaton.com> Date: Sat, 12-Sep-87 18:59:10 EDT Article-I.D.: etn-wlv.8709122259.AA05868 Posted: Sat Sep 12 18:59:10 1987 Date-Received: Sun, 13-Sep-87 09:04:34 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Dennis: I'm a little confused. The LONEX Mail Facility does indicate who the cc: recipients are on each message when you display the message. Of course, there may be some slight differences between the RADC and EATON versions. A definitive answer can be gotten from Steven M Schultz (sms@etn-wlv.eaton.com) currently on location (sms@radc-lonex.arpa) about any differences. Merton Campbell Crockett ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091215060000> Received: from Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Sat 12 Sep 87 07:10:07-PDT Received: from ucl-cs-pyr1 by nss.Cs.Ucl.AC.UK via Ethernet with SMTP id aa01374; 12 Sep 87 15:09 BST Date: Sat, 12 Sep 87 15:06:00 GMT-0:00 From: Zheng Wang To: tcp-ip@sri-nic.arpa Subject: IP Options What will happen if a packet with a source route option goes through a unix 4.2 gateway ? Will the gateway strip the option out after updating ? Zheng. zwang@uk.ac.ucl.cc ----MESSAGE-END---- ----MESSAGE-BEGIN---- [558486541.0.PERRY@VAX.DARPA.MIL] <1987091215090100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: [VWHITE@NSWC-G.ARPA:] Message-ID: <558486541.0.PERRY@VAX.DARPA.MIL> Date: Sat, 12-Sep-87 19:09:01 EDT Article-I.D.: VAX.558486541.0.PERRY Posted: Sat Sep 12 19:09:01 1987 Date-Received: Sun, 13-Sep-87 09:05:19 EDT References: <8709122259.AA05868@etn-wlv.eaton.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Merton, we made a test, and at least the RADC lonex does not include any names on the cc line. It does indeed send copies of the mail to those indicated on the cc lines of the lonex user who generates the mail, but the mail that is sent out does not include that information. Instead, lonex generates a mail message to everyone as if they were the only one getting the message. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [6211@sgi.SGI.COM] <1987091217021100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: vjs@sgi.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: IP options Message-ID: <6211@sgi.SGI.COM> Date: Sat, 12-Sep-87 21:02:11 EDT Article-I.D.: sgi.6211 Posted: Sat Sep 12 21:02:11 1987 Date-Received: Sun, 13-Sep-87 10:22:26 EDT References: <423@root44.co.uk> <8709092006.AA09597@okeeffe.Berkeley.EDU> Sender: daemon@sgi.SGI.COM Organization: Silicon Graphics Inc, Mountain View, CA Lines: 21 Summary: fix does not compile In article <8709092006.AA09597@okeeffe.Berkeley.EDU>, karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels) writes: > + * Also, don't send redirect if forwarding using a default route > + * or a route modfied by a redirect. > */ > + #define satosin(sa) ((struct sockaddr_in *)(sa)) > if (ipforward_rt.ro_rt && ipforward_rt.ro_rt->rt_ifp == ifp && > + (ipforward_rt.ro_rt->rt_flags & (RTF_DYNAMIC|RTF_MODIFIED)) == 0 && > + satosin(&ipforward_rt.ro_rt->rt_dst)->sin_addr.s_addr != 0 && > ipsendredirects && ip->ip_hl == (sizeof(struct ip) >> 2)) { I have been faithfully following the 4.3 fixes posted here and in the 'official' news group. However, RTF_MODIFIED does not seem to be defined in my source. If I have missed something, would someone please give me a pointer to it? Else, might there be fixes pending to #define it and to set it? Thank you Vernon Schryver Silicon Graphics, Inc vjs@sgi.com or {decwrl,pyramid,sun,ucbvax,allegra}!sgi!vjs ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12334192173.6.SATZ@MATHOM.CISCO.COM] <1987091221011100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: SATZ@MATHOM.CISCO.COM (Greg Satz) Newsgroups: comp.protocols.tcp-ip Subject: DDN X.25 mapping Message-ID: <12334192173.6.SATZ@MATHOM.CISCO.COM> Date: Sun, 13-Sep-87 01:01:11 EDT Article-I.D.: MATHOM.12334192173.6.SATZ Posted: Sun Sep 13 01:01:11 1987 Date-Received: Sun, 13-Sep-87 19:46:09 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 What should a DDN X.25 interface do about mapping to X.121 addresses when connected to a class B or C network? I remember seeing something about this before somewhere. If I remember correctly the C and D octets should be used for the imp and host octets for class B addresses. For class C, the upper four bits and the lower four bits of octet D should be used for the imp and host octets. Is this correct? ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [15347@hi.UUCP] <1987091311484900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kurt@hi.UUCP (Kurt Zeilenga) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans Subject: T1 and distant IP networks Message-ID: <15347@hi.UUCP> Date: Sun, 13-Sep-87 15:48:49 EDT Article-I.D.: hi.15347 Posted: Sun Sep 13 15:48:49 1987 Date-Received: Sun, 13-Sep-87 21:50:09 EDT Organization: U. of New Mexico, Albuquerque Lines: 9 Keywords: T1 ethernet IP We have: 1) two IP ethernets separated by 120 miles 2) a T1 line between the two. I would like an IP (or ethernet if IP wasn't readly available) repeater or bridge or gateway so the two networks can talk. Anybody have any information about off the shelf products that could be used. Cost estimates would be greatly appreciated. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12334391704.24.ROODE@BIONET-20.ARPA] <1987091315171400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROODE@BIONET-20.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: EMail User Agents Message-ID: <12334391704.24.ROODE@BIONET-20.ARPA> Date: Sun, 13-Sep-87 19:17:14 EDT Article-I.D.: BIONET-2.12334391704.24.ROODE Posted: Sun Sep 13 19:17:14 1987 Date-Received: Tue, 15-Sep-87 01:35:31 EDT References: <16393@teknowledge-vaxc.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 60 mkhaw@teknowledge cites several specifics of Unix MM-32 which I agree are points which could stand improvement or clarification. Many mail programs seem to keep mail in their own format so this concern is common. I wasn't alluding to incompatibility with Unix or similarity to TOPS-20 as the basis for suggesting taking a look at MM-32. Specifically, the features in MM-32 that I think recommend it as an improvement over other Unix mail agents are: a) a ? feature for all commands and command options The user need not know the options in advance to select them; nor need he depart from command interaction to consult separate help text for the command. b) a distinct top level; i.e. the individual mail commands are not merged in with the Unix shell commands. I think this is a plus for user understanding. c) a mode change between the top level of the mail program and the level under which a particular message is being processed. Again, I think clarity is enhanced when distinctions are made as to context of user interaction. d) profile capability including the ability to suppress display of selected headers when they appear in messages e) flexible specification of message sequences, i.e. to perform an action on sequences specified by compound conditions such as 'from joe' and 'since 15 May 1987'; the mere ability to identify messages to include in a sequence by one attribute of the messages intended let alone ability to compound them f) capability to search with messages with a certain text string in the message body Characteristics which I would find highly valuable but which MM-32 does not have are as follows: A mode when reading messages to allow display of only the first n lines of message body. At that point a one keystroke selection should allow for continuation; otherwise all other message disposition options ought to be valid. Ability to specify automatic disposition with optional confirmation, i.e. "when reading messages addressed to 'SPECIAL-COMMITTEE' by default save them in file 'SPECIAL-COMMITTEE.FILE'"; "when reading messages from Joe, by default place them in file Joe.mail but confirm first"; when reading messages addressed to 'announcements' delete them after reading; when reading all other messages not addressed directly to myself, place them in file 'LIST.MAIL'" I think the last set of mail processing capabilities is very simple yet provide a very powerful tool for managing a history of online EMAIL. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709132326.AA04790@topaz.rutgers.edu] <1987091315263000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: DDN X.25 mapping Message-ID: <8709132326.AA04790@topaz.rutgers.edu> Date: Sun, 13-Sep-87 19:26:30 EDT Article-I.D.: topaz.8709132326.AA04790 Posted: Sun Sep 13 19:26:30 1987 Date-Received: Tue, 15-Sep-87 01:35:54 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 There is no standard for the IMP to Class B and C addresses that I know of. HOWEVER, both BRL and the Canadian version of MILNET use the C octet for host number and the D octet for imp number (essentially sliding the HOST byte right one byte). -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091401384900> Received: from GUNTER-ADAM.ARPA by SRI-NIC.ARPA with TCP; Mon 14 Sep 87 04:37:45-PDT Date: 14 Sep 1987 06:38:49 CDT From: SITT@GUNTER-ADAM.ARPA Subject: Romove From Mailing List To: tcp-ip@SRI-NIC.ARPA cc: sitt@GUNTER-ADAM.ARPA Please remove this account from the mailing list. sitt"at"gunter-adam.arpa ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709141117.AA14888@topaz.rutgers.edu] <1987091403172900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: T1 and distant IP networks Message-ID: <8709141117.AA14888@topaz.rutgers.edu> Date: Mon, 14-Sep-87 07:17:29 EDT Article-I.D.: topaz.8709141117.AA14888 Posted: Mon Sep 14 07:17:29 1987 Date-Received: Tue, 15-Sep-87 04:40:21 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 There are a couple of ways to go. Since you are already IP oriented, I'd suggest IP bridges. We use ones from CISCO systems to bridge several T1 lines to Ethernets here. Proteon makes a similar box. Expect them to cost you $7000-10,000 an end. Ungermann/Bass makes a IP bridge (which can also be an Ethernet bridge (same hardware)) which is probably a little cheaper but their IP isn't quite as mature as the others. We currently run the UB box in ethernet bridge mode (I don't know how much it cost, I didn't buy it). -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709141143.AA22175@ucbvax.Berkeley.EDU] <1987091403384900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: SITT@GUNTER-ADAM.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Romove From Mailing List Message-ID: <8709141143.AA22175@ucbvax.Berkeley.EDU> Date: Mon, 14-Sep-87 07:38:49 EDT Article-I.D.: ucbvax.8709141143.AA22175 Posted: Mon Sep 14 07:38:49 1987 Date-Received: Tue, 15-Sep-87 04:41:06 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Please remove this account from the mailing list. sitt"at"gunter-adam.arpa ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091404074800> Received: from CC5.BBN.COM by SRI-NIC.ARPA with TCP; Mon 14 Sep 87 07:59:32-PDT To: Greg Satz , Ron Natalie cc: tcp-ip@SRI-NIC.ARPA, malis@CC5.BBN.COM, hinden@CC5.BBN.COM Subject: Re: DDN X.25 mapping In-reply-to: Your message of Sun, 13 Sep 87 19:26:30 -0400. <8709132326.AA04790@topaz.rutgers.edu> Date: Mon, 14 Sep 87 10:47:48 -0400 From: Andy Malis Greg, Ron is correct, RFC 796 only discusses the Class A mapping between IP addresses and ARPANET/MILNET addresses. He described the generally accepted mapping for Class B IP addresses, using the third octet for the host number and the fourth octet for the PSN (IMP) number. PLEASE remember to follow the algorithm in section A-5 of the DDN X.25 Host Interface Spec (BBN Report 5476, in the DDN Protocol Handbook, Vol 1, as section 6.6) for deriving the X.25 address, so that logical addressing will work correctly. All you have to do is substitute the third octet of a Class B IP address for the 2nd octet of a Class A IP address as discussed in the algorithm. This is on pages A-9 and A-10 of the spec (pages 1-497 and 1-498 of the Protocol Handbook). There is no generally accepted standard for Class C addresses, nor am I aware of any Class C PSN-based networks. Certainly, 4 bits for each of the host and PSN numbers would work - it depends on the number of PSNs in the network and the maximum number of hosts on each PSN. This mapping should probably be customized on a network-by-network basis. For consistency with the Class A and Class B mappings, the host number bits should be in the more significant bits of the 4th octet. Regards, Andy Malis PSN Development ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091405364100> Received: from CC5.BBN.COM by SRI-NIC.ARPA with TCP; Mon 14 Sep 87 09:26:56-PDT To: WANCHO@SIMTEL20.ARPA cc: TCP-IP@SRI-NIC.ARPA, malis@CC5.BBN.COM, seisner@CC5.BBN.COM Subject: Re: Can of worms... In-reply-to: Your message of Fri, 11 Sep 87 10:50:00 -0600. Date: Mon, 14 Sep 87 12:16:41 -0400 From: Andy Malis Frank, As a host administrator myself (as well as a PSN code developer), I understand your concern about the costs generated by the usage-sensitive chargeback. However, I can find several problems with your proposed "collect call" connections: 1. Even though AHIP traffic is sent by the network using internal connections, the AHIP host interface is not explicitly connection-based. There are two alternative ways a host could identify "collect calls": a. Add explicit connection-based mechanisms to AHIP. This would effectively turn AHIP into a variant of X.25, and would require a very large implementation effort in the PSNs and in hosts. By the way, this would be required for the network to be able to automatically charge a host for all traffic it generates in BOTH directions of a call it originates, as you suggested. b. Add a bit to the AHIP message leader, specifying collect charging for this message. This would require that for each such message, a receiving host would need some sort of reply mechanism to either "accept" or "reject" such a message. These acceptances or rejections would have to be passed back through the network to the originating host, which would have to send them back up to the IP and TCP layers. This, again, could not be classified as a "trivial" change to either the PSN or host software. And what do you do about hosts that don't upgrade? Are they forced to accept these charges they cannot detect? Or did you have something else in mind? 2. Given a method to identify "collect calls", how does the sending host's AHIP driver know to use it? Does the TCP driver send down, through the IP driver, information that identifies certain packets as "collect"? How does the TCP driver know? For example, how does the mailer daemon distinguish mail that is to be sent collect from mail to be sent normally? How does the user FTP program know, when it establishes the FTP connection with the other host's FTP server, that the user plans to log in to the server using an "anonymous" login? You see possible problems. 3. How does a host receiving "collect" messages know whether to accept them or not? If hosts just blindly accept all collect messages or calls, then I can program my host to ALWAYS send traffic collect. 4. The DDN PMO generally considers AHIP to be fading away as more X.25 hosts join the ARPANET and MILNET. They are also very resistant to any changes to AHIP that require changes in host software, because they have no control over the hosts and their AHIP implementation. For these reasons, there is no assurance that AHIP-E will ever be accepted and implemented (don't start those host implementations yet, folks). In fact, I am currently working on defining an alternative to AHIP-E that will require NO changes in host software. 5. The only PSN work the DDN has currently authorized for this usage-sensitive charging is to add usage data collection and reporting to the AHIP interface code. This function already exists for the X.25 interface. They have not authorized any changes to the actual AHIP interface for this. There are other problems I could probably bring up as well, but you get the point - a technical solution at the PSN level isn't really feasible. If you are concerned about the costs of your host's traffic levels, my advice is to look into methods of controlling the traffic (such as some that you suggested yourself), or seek an administrative solution by bringing up these issues with the DDN PMO before they finalize their charging policies. I am also curious why you would consider discontinuing TAC access for your regular users. Any DDN charges for this access should be directly recoverable from your users. Regards, Andy Malis PSN Development ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091405534000> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Mon 14 Sep 87 09:34:25-PDT To: Mills@LOUIE.UDEL.EDU cc: tcp-ip@SRI-NIC.ARPA, egp-people@PARK-STREET.BBN.COM Subject: Re: EGP updates over the top In-reply-to: Your message of Fri, 11 Sep 87 22:13:07 -0400. <8709112213.aa23967@Huey.UDEL.EDU> Date: Mon, 14 Sep 87 12:33:40 -0400 From: Mike Brescia The number of nets has indeed been sloshing about the arpanet update size limit, the 1006 octet MTU. The fragmenting of NR messages sent by core systems will be happenning with the next release of software to the butterfly and lsi11 gateways. If you want to try some pre-release tests, we can send you some test gateway addresses to try this week. Re: the DON'T FRAGMENT (DF) bit in the IP header; a meaning has been assigned for use of gateway implementations which do not initially do reassembly. If a poll message is received with the DF bit set, the NR message sent in reply will be truncated to fit the (1006) MTU of the net. Thus you can get SOME info until the time when your gateway implements reassembly. NOTE: This meaning is only in the new code which has the capability of doing fragmentation and reassembly. The current release which does not do reassembly will only send as many nets as fit in 1000 (+/-) octets. Look for announcements of debugging this week. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [111@cunixc.columbia.edu] <1987091406392600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: howie@cunixc.columbia.edu (Howie Kaye) Newsgroups: comp.protocols.tcp-ip Subject: Re: EMail User Agents Message-ID: <111@cunixc.columbia.edu> Date: Mon, 14-Sep-87 10:39:26 EDT Article-I.D.: cunixc.111 Posted: Mon Sep 14 10:39:26 1987 Date-Received: Tue, 15-Sep-87 05:45:32 EDT References: <16393@teknowledge-vaxc.ARPA> <12334391704.24.ROODE@BIONET-20.ARPA> Reply-To: howie@cunixc.columbia.edu (Howie Kaye) Organization: Columbia University Center for Computing Activities Lines: 21 Another version of MM is currently being written at Columbia University, under a User interface package called CCMD. This is an expanded Tops-20 like interface, as described in the message about MM-32. This MM program will be mostly compatible with the TOPS20 version, though it will support several mail file types, and will eventually run as a POP client. CCMD currently runs under Berkeley and sysV UNIX, and MSDOS. MM will also run on all of these (Only as a POP client under MSDOS though.) Mail to info-topsux-request@cu20b.columbia.edu, or info-ccmd-request@cu20b.columbia.edu for more information.] ------------------------------------------------------------ Howie Kaye howie@columbia.edu Columbia University hlkcu@cuvma.bitnet Systems Group ...!rutgers!columbia!howie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709141456.AA04409@umd5.UMD.EDU] <1987091406565100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dzoey@UMD5.UMD.EDU Newsgroups: comp.protocols.tcp-ip Subject: user interface for urgent data. Message-ID: <8709141456.AA04409@umd5.UMD.EDU> Date: Mon, 14-Sep-87 10:56:51 EDT Article-I.D.: umd5.8709141456.AA04409 Posted: Mon Sep 14 10:56:51 1987 Date-Received: Tue, 15-Sep-87 05:40:46 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Hi, I was looking at the TCP spec (RFC 793) and became slightly curious about how urgent data should be presented to the application. Berkeley has the application either register a function to handle the urgent data seperately, or indicate that urgent data should be delivered as normal data. This seems like a reasonable thing to do, but I'm curious about how other implementations present urgent data. I'd very much like to hear about how other implementations do this. Another question I have is where does the urgent data start? Is it safe to assume at the beginning of a packet marked as urgent? If all the data in a packet marked urgent is urgent data, then shouldn't urgent data be delivered as soon as possible (i.e. not wait for sequence reassembly since you know all data in that packet is urgent and would be delivered out of sequence anyway)? Is there something I should have read before asking this? Thanks for any info Joe Herman dzoey@umd5.umd.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709141516.AA24854@ucbvax.Berkeley.EDU] <1987091407183500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: malis@CC5.BBN.COM (Andy Malis) Newsgroups: comp.protocols.tcp-ip Subject: Re: DDN X.25 mapping Message-ID: <8709141516.AA24854@ucbvax.Berkeley.EDU> Date: Mon, 14-Sep-87 11:18:35 EDT Article-I.D.: ucbvax.8709141516.AA24854 Posted: Mon Sep 14 11:18:35 1987 Date-Received: Tue, 15-Sep-87 05:41:31 EDT References: <8709132326.AA04790@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 29 Greg, Ron is correct, RFC 796 only discusses the Class A mapping between IP addresses and ARPANET/MILNET addresses. He described the generally accepted mapping for Class B IP addresses, using the third octet for the host number and the fourth octet for the PSN (IMP) number. PLEASE remember to follow the algorithm in section A-5 of the DDN X.25 Host Interface Spec (BBN Report 5476, in the DDN Protocol Handbook, Vol 1, as section 6.6) for deriving the X.25 address, so that logical addressing will work correctly. All you have to do is substitute the third octet of a Class B IP address for the 2nd octet of a Class A IP address as discussed in the algorithm. This is on pages A-9 and A-10 of the spec (pages 1-497 and 1-498 of the Protocol Handbook). There is no generally accepted standard for Class C addresses, nor am I aware of any Class C PSN-based networks. Certainly, 4 bits for each of the host and PSN numbers would work - it depends on the number of PSNs in the network and the maximum number of hosts on each PSN. This mapping should probably be customized on a network-by-network basis. For consistency with the Class A and Class B mappings, the host number bits should be in the more significant bits of the 4th octet. Regards, Andy Malis PSN Development ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091407561900> Received: from CC5.BBN.COM by SRI-NIC.ARPA with TCP; Mon 14 Sep 87 11:50:48-PDT To: WANCHO@SIMTEL20.ARPA cc: TCP-IP@SRI-NIC.ARPA Subject: Re: Can of worms... In-reply-to: Your message of Fri, 11 Sep 87 10:50:00 -0600. Date: Mon, 14 Sep 87 14:36:19 -0400 From: seisner@CC5.BBN.COM Frank, Just to add to Andy's message - the X.25 interface already supports the reverse charging facilities you desire, and so will the accounting system we will be putting in, for X.25 connections. So, one way to get what you want is to convert your direct host interface(s) from AHIP to X.25, if that's at all a possibility. Regards, Sharon Eisner PSN Development ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709141556.AA00477@mercury.mitre.org] <1987091407563300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mankin@GATEWAY.MITRE.ORG Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8709141556.AA00477@mercury.mitre.org> Date: Mon, 14-Sep-87 11:56:33 EDT Article-I.D.: mercury.8709141556.AA00477 Posted: Mon Sep 14 11:56:33 1987 Date-Received: Tue, 15-Sep-87 06:17:05 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Z. Wang asked what happens to a source route option in a 4.2 gateway. It depends what you mean by a 4.2 gateway. The original Berkeley release of 4.2 has a typo in the code in ip_stripoptions (a bcopy to m instead of mopt--easy to see) which crashes the machine when an IP packet with *any* option is forwarded. The Ultrix version of 4.2 does not have this bug. If this bug is fixed, the updated option goes out on the forwarded packet. Allison ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709141635.AA26572@ucbvax.Berkeley.EDU] <1987091408412300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: malis@CC5.BBN.COM (Andy Malis) Newsgroups: comp.protocols.tcp-ip Subject: Re: Can of worms... Message-ID: <8709141635.AA26572@ucbvax.Berkeley.EDU> Date: Mon, 14-Sep-87 12:41:23 EDT Article-I.D.: ucbvax.8709141635.AA26572 Posted: Mon Sep 14 12:41:23 1987 Date-Received: Tue, 15-Sep-87 06:18:10 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 84 Frank, As a host administrator myself (as well as a PSN code developer), I understand your concern about the costs generated by the usage-sensitive chargeback. However, I can find several problems with your proposed "collect call" connections: 1. Even though AHIP traffic is sent by the network using internal connections, the AHIP host interface is not explicitly connection-based. There are two alternative ways a host could identify "collect calls": a. Add explicit connection-based mechanisms to AHIP. This would effectively turn AHIP into a variant of X.25, and would require a very large implementation effort in the PSNs and in hosts. By the way, this would be required for the network to be able to automatically charge a host for all traffic it generates in BOTH directions of a call it originates, as you suggested. b. Add a bit to the AHIP message leader, specifying collect charging for this message. This would require that for each such message, a receiving host would need some sort of reply mechanism to either "accept" or "reject" such a message. These acceptances or rejections would have to be passed back through the network to the originating host, which would have to send them back up to the IP and TCP layers. This, again, could not be classified as a "trivial" change to either the PSN or host software. And what do you do about hosts that don't upgrade? Are they forced to accept these charges they cannot detect? Or did you have something else in mind? 2. Given a method to identify "collect calls", how does the sending host's AHIP driver know to use it? Does the TCP driver send down, through the IP driver, information that identifies certain packets as "collect"? How does the TCP driver know? For example, how does the mailer daemon distinguish mail that is to be sent collect from mail to be sent normally? How does the user FTP program know, when it establishes the FTP connection with the other host's FTP server, that the user plans to log in to the server using an "anonymous" login? You see possible problems. 3. How does a host receiving "collect" messages know whether to accept them or not? If hosts just blindly accept all collect messages or calls, then I can program my host to ALWAYS send traffic collect. 4. The DDN PMO generally considers AHIP to be fading away as more X.25 hosts join the ARPANET and MILNET. They are also very resistant to any changes to AHIP that require changes in host software, because they have no control over the hosts and their AHIP implementation. For these reasons, there is no assurance that AHIP-E will ever be accepted and implemented (don't start those host implementations yet, folks). In fact, I am currently working on defining an alternative to AHIP-E that will require NO changes in host software. 5. The only PSN work the DDN has currently authorized for this usage-sensitive charging is to add usage data collection and reporting to the AHIP interface code. This function already exists for the X.25 interface. They have not authorized any changes to the actual AHIP interface for this. There are other problems I could probably bring up as well, but you get the point - a technical solution at the PSN level isn't really feasible. If you are concerned about the costs of your host's traffic levels, my advice is to look into methods of controlling the traffic (such as some that you suggested yourself), or seek an administrative solution by bringing up these issues with the DDN PMO before they finalize their charging policies. I am also curious why you would consider discontinuing TAC access for your regular users. Any DDN charges for this access should be directly recoverable from your users. Regards, Andy Malis PSN Development ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709141648.AA26872@ucbvax.Berkeley.EDU] <1987091408504500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@PARK-STREET.BBN.COM (Mike Brescia) Newsgroups: comp.protocols.tcp-ip Subject: Re: EGP updates over the top Message-ID: <8709141648.AA26872@ucbvax.Berkeley.EDU> Date: Mon, 14-Sep-87 12:50:45 EDT Article-I.D.: ucbvax.8709141648.AA26872 Posted: Mon Sep 14 12:50:45 1987 Date-Received: Tue, 15-Sep-87 06:24:36 EDT References: <8709112213.aa23967@Huey.UDEL.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 The number of nets has indeed been sloshing about the arpanet update size limit, the 1006 octet MTU. The fragmenting of NR messages sent by core systems will be happenning with the next release of software to the butterfly and lsi11 gateways. If you want to try some pre-release tests, we can send you some test gateway addresses to try this week. Re: the DON'T FRAGMENT (DF) bit in the IP header; a meaning has been assigned for use of gateway implementations which do not initially do reassembly. If a poll message is received with the DF bit set, the NR message sent in reply will be truncated to fit the (1006) MTU of the net. Thus you can get SOME info until the time when your gateway implements reassembly. NOTE: This meaning is only in the new code which has the capability of doing fragmentation and reassembly. The current release which does not do reassembly will only send as many nets as fit in 1000 (+/-) octets. Look for announcements of debugging this week. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091409065100> Received: from CC5.BBN.COM by SRI-NIC.ARPA with TCP; Mon 14 Sep 87 12:58:59-PDT To: WANCHO@SIMTEL20.ARPA, seisner@CC5.BBN.COM cc: TCP-IP@SRI-NIC.ARPA, malis@CC5.BBN.COM Subject: Re: Can of worms... In-reply-to: Your message of Mon, 14 Sep 87 14:36:19 -0400. Date: Mon, 14 Sep 87 15:46:51 -0400 From: Andy Malis Frank, What Sharon forgot to mention is that while the X.25 interface does support reverse charging, the protocol layering and charging algorithm issues that I raised still need to be resolved before reverse charging can or should be actively used. At least the PSN implementation that you need is available, now all you need is agreement on how and when to use it ... Regards, Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091409103700> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Mon 14 Sep 87 12:56:33-PDT To: Mills@LOUIE.UDEL.EDU cc: Mike Brescia , tcp-ip@SRI-NIC.ARPA, egp-people@PARK-STREET.BBN.COM Subject: Re: EGP updates over the top In-reply-to: Your message of Mon, 14 Sep 87 13:13:02 -0400. <8709141313.aa24367@Huey.UDEL.EDU> Date: Mon, 14 Sep 87 15:50:37 -0400 From: Mike Brescia Re: sending fragments - not yet in core 1. Except for a short time around the beginning of August, new code to fragment EGP NR messages has not yet been run in the LSI11's. Around that time, the code was run up on BBN2 and PURDUE for a few hours. 2. The LSI11's will copy the dont-fragment (DF) bit from the IP header of a EGP POLL request into the NR reply. This sounds like what you are seeing. Since the LSI11 was going to truncate the message anyway, the bit was essentially ignored. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709141313.aa24367@Huey.UDEL.EDU] <1987091409130200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: EGP updates over the top Message-ID: <8709141313.aa24367@Huey.UDEL.EDU> Date: Mon, 14-Sep-87 13:13:02 EDT Article-I.D.: Huey.8709141313.aa24367 Posted: Mon Sep 14 13:13:02 1987 Date-Received: Tue, 15-Sep-87 06:29:48 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Mike, Are you sure the new code has not escaped to ISI, PURDUE or BBN2? The behavior I noticed last week, including the DF bit, occured with one or more of those buzzards. Not to worry, though. At least the fuzz now do buzz EGP reassembly. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709141820.AA23401@faline.bellcore.com] <1987091410202400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@FALINE.BELLCORE.COM (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: Re: T1 and distant IP networks Message-ID: <8709141820.AA23401@faline.bellcore.com> Date: Mon, 14-Sep-87 14:20:24 EDT Article-I.D.: faline.8709141820.AA23401 Posted: Mon Sep 14 14:20:24 1987 Date-Received: Tue, 15-Sep-87 06:44:21 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Another way to go is to interconnect at the link (Ethernet) layer using Vitalink Translan III bridges. They support line speeds up to T1. We've been running a half dozen of them within Bellcore for a year now and they have been working very nicely. We have five large locations and about 1000 hosts in our host table. During a typical daytime minute, several hundred hosts may be active. At the moment most of our links are 250 kbps; one is already T1. All links will soon be upgraded to T1 when our DS-3 fibers are installed. The big advantage of bridging is that you can run any protocol you want across them; it doesn't have to be IP. Another is that you can freely move hosts between cable segments without having to change addresses; in a large network like ours, the administrative savings are substantial. The main disadvantage is that broadcasts go everywhere, although with T1's bandwidth this isn't much of a problem. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709141833.AA02525@ACC-SB-UNIX.ARPA] <1987091410332500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rms@ACC-SB-UNIX.ARPA (Ron Stoughton) Newsgroups: comp.protocols.tcp-ip Subject: Re: ACC's ACCES/MVS Message-ID: <8709141833.AA02525@ACC-SB-UNIX.ARPA> Date: Mon, 14-Sep-87 14:33:25 EDT Article-I.D.: ACC-SB-U.8709141833.AA02525 Posted: Mon Sep 14 14:33:25 1987 Date-Received: Tue, 15-Sep-87 06:45:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 74 I would like to expand a bit on the comments Bob Dixon made regarding his experience with ACCES/MVS: > We use UCLA mail to front-end smtp. That causes minor problems as UCLA > mail does not allow the full smtp address syntax. Henry Nussbacher (HANK%BARILVM.BITNET@wiscvm.wisc.edu) told me recently that an associate of his has made some improvements to UCLA/MAIL, one being recognition of internet domain names. I believe these changes have been provided to UCLA, but I don't know for sure whether they are included in the public domain release. I can get you a name of a contact if you are interested in more information. > Full-screen telnet to a VM system running KNET does not work. 3270 over Telnet requires three negotiations to take place before going into full-screen mode -- terminal type (e.g., IBM-3278-2), end-of-record (EOR), and binary. When ACCES/MVS is the server, KNET refuses the EOR negotiations by returning WON'T/DON'T EOR in response to our DO/WILL EOR. This causes our server to end up in binary (EBCDIC) line-at-a-time mode, while the KNET client thinks (erroneously) that it is in full-screen 3270 mode. Our transmissions to the client are therefore terminated with an EBCDIC , and KNET is waiting for an sequence. The reverse is true in the opposite direction. At this point the Telnet session appears hung. When ACCES/MVS is the client, KNET rejects our terminal type (IBM-3278-2) and requests that we resend it with another sub-negotiation. We don't and we probably should, but even if we did, KNET does not negotiate EOR which would leave us in the state as described above. I suspect that KNET is getting confused because our sub-negotiation response is being split into two transmissions -- in the first message followed by IBM-3278-2 in the second (it's a stream protocol folks). Bob Braden has suggested that the 3270 negotiation protocol could be changed to imply EOR if, but only if, terminal type and binary are successfully negotiated, and the terminal type is IBM-3278. There is a separate group of vendors and users debating this issue. If and when there is a consensus that the protocol should be changed, we will comply. In the meantime, KNET should conform to the protocol. > FTP is very powerful in dealing with MVS files, but requires the user > to supply the MVS volume name, which is a pain. We agree, and as a result we have removed this wart, along with many others, in the latest release (2.0). If a volume name is not provided, a default volume is used. Also, DSCB attributes are now retained when writing to pre- allocated data sets. We think we have made simple transfers simple by eliminating the need to use the SITE (i.e., Unix quote) command. We en- courage our users to upgrade to the new release. > FTP allows file transfer between any 2 computers, neither of which needs > to be the MVS system. This is useful, but requires the user to provide > login info for MVS twice if one of the systems is MVS. Bob Dixon was kinder than most in describing this feature. Many users who have been introduced to networking via Unix have found the three-party model confusing, or at least more cumbersome to use. Therefore, we have rewritten the MVS FTP client to implement the command syntax of a Unix client, and mimic a two-party model (the local MVS session is hidden). This allows us to maintain the performance advantages of a three-party model (the file does not need to pass through VTAM and the TSO address space) while gaining the simplicity inherent in the two-party model. This will be available in Release 2.1 which is close to being out the door. Incidentally, before I get growls from this mailing list, I should acknowledge that we don't hold the Unix FTP client as the model of perfection, but it does provide a measure of acceptance. Therefore, we implemented it as an alternative until we can provide an SPF panel-driven client which may be a more natural interface for an IBM TSO user. Ron Stoughton rms@acc-sb-unix.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709141836.AA24625@faline.bellcore.com] <1987091410364300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@FALINE.BELLCORE.COM (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: FTP advisory messages Message-ID: <8709141836.AA24625@faline.bellcore.com> Date: Mon, 14-Sep-87 14:36:43 EDT Article-I.D.: faline.8709141836.AA24625 Posted: Mon Sep 14 14:36:43 1987 Date-Received: Tue, 15-Sep-87 06:45:50 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 A lot of new FTP users (and some veteran ones, too) get bitten by forgetting to say "type image" before sending a binary file. You get no warning when you do this; you don't discover your mistake until you're done and find that the file is corrupted. I would like to add an advisory message to my own FTP server to warn the user when he/she does this. The FTP client should just display this message to the user but otherwise ignore it, relying on the user to abort the transfer. But how should I do this? I seem to remember that there are reply messages of the "0XX" class that would do what I want, but I can't find it mentioned anywhere in the specs. Comments? Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709141917.AA00538@ucbvax.Berkeley.EDU] <1987091411192400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: seisner@CC5.BBN.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: Can of worms... Message-ID: <8709141917.AA00538@ucbvax.Berkeley.EDU> Date: Mon, 14-Sep-87 15:19:24 EDT Article-I.D.: ucbvax.8709141917.AA00538 Posted: Mon Sep 14 15:19:24 1987 Date-Received: Tue, 15-Sep-87 06:46:02 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Frank, Just to add to Andy's message - the X.25 interface already supports the reverse charging facilities you desire, and so will the accounting system we will be putting in, for X.25 connections. So, one way to get what you want is to convert your direct host interface(s) from AHIP to X.25, if that's at all a possibility. Regards, Sharon Eisner PSN Development ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12334620403.6.MRC@PANDA.COM] <1987091412133100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MRC@PANDA.COM (Mark Crispin) Newsgroups: comp.protocols.tcp-ip Subject: Re: DDN X.25 mapping Message-ID: <12334620403.6.MRC@PANDA.COM> Date: Mon, 14-Sep-87 16:13:31 EDT Article-I.D.: PANDA.12334620403.6.MRC Posted: Mon Sep 14 16:13:31 1987 Date-Received: Tue, 15-Sep-87 07:07:57 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 For the record, both BBN and PANDA TOPS-20 assume that any Class C PSN-based network will have the host number in the high order 2 bits, and the PSN in the low order 6 bits of the fourth octet. This is the format which we used in the good old days of NCP and 32-bit leaders, for those of us old enough to remember that far back (am I betraying my age????). DEC TOPS-20 doesn't handle non-class A PSN's at all, nor does any version of TOPS-20 I know of handle X.25 interfaces (the DEC IMPterface is an 1822 device). I think that DEC is adopting the PANDA algorithm though. I know of no controversy about the format a Class B PSN network address, or, at least TOPS-20 and Unix agree on having the host number in the third octet and the PSN number in the fourth octet. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709142015.AA01822@ucbvax.Berkeley.EDU] <1987091412173000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: malis@CC5.BBN.COM (Andy Malis) Newsgroups: comp.protocols.tcp-ip Subject: Re: Can of worms... Message-ID: <8709142015.AA01822@ucbvax.Berkeley.EDU> Date: Mon, 14-Sep-87 16:17:30 EDT Article-I.D.: ucbvax.8709142015.AA01822 Posted: Mon Sep 14 16:17:30 1987 Date-Received: Tue, 15-Sep-87 07:03:09 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Frank, What Sharon forgot to mention is that while the X.25 interface does support reverse charging, the protocol layering and charging algorithm issues that I raised still need to be resolved before reverse charging can or should be actively used. At least the PSN implementation that you need is available, now all you need is agreement on how and when to use it ... Regards, Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709142003.AA01507@ucbvax.Berkeley.EDU] <1987091412392000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@PARK-STREET.BBN.COM (Mike Brescia) Newsgroups: comp.protocols.tcp-ip Subject: Re: EGP updates over the top Message-ID: <8709142003.AA01507@ucbvax.Berkeley.EDU> Date: Mon, 14-Sep-87 16:39:20 EDT Article-I.D.: ucbvax.8709142003.AA01507 Posted: Mon Sep 14 16:39:20 1987 Date-Received: Tue, 15-Sep-87 07:08:21 EDT References: <8709141313.aa24367@Huey.UDEL.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Re: sending fragments - not yet in core 1. Except for a short time around the beginning of August, new code to fragment EGP NR messages has not yet been run in the LSI11's. Around that time, the code was run up on BBN2 and PURDUE for a few hours. 2. The LSI11's will copy the dont-fragment (DF) bit from the IP header of a EGP POLL request into the NR reply. This sounds like what you are seeing. Since the LSI11 was going to truncate the message anyway, the bit was essentially ignored. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709142206.AA06229@okeeffe.Berkeley.EDU] <1987091414063400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels) Newsgroups: comp.protocols.tcp-ip Subject: Re: IP options Message-ID: <8709142206.AA06229@okeeffe.Berkeley.EDU> Date: Mon, 14-Sep-87 18:06:34 EDT Article-I.D.: okeeffe.8709142206.AA06229 Posted: Mon Sep 14 18:06:34 1987 Date-Received: Wed, 16-Sep-87 01:18:52 EDT References: <6211@sgi.SGI.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 141 Oops. I created a special version of the ip_input.c file with the fixes I wanted to send but without post-4.3 changes that wouldn't work with everyone else's system, but I missed one change (RTF_MODIFIED wasn't in 4.3). For those who have been trying to install the change I sent out last week, here it is again in a form that should work with 4.3. Mike *** /nbsd/usr/src.4.3/sys/netinet/ip_input.c Thu Jun 5 00:28:15 1986 --- ip_input.c Mon Sep 14 14:59:07 1987 *************** *** 5,7 **** * ! * @(#)ip_input.c 7.1 (Berkeley) 6/5/86 */ --- 5,7 ---- * ! * @(#)ip_input.c 7.6.1.2 (Berkeley) 9/14/87 */ *************** *** 302,304 **** if (fp == 0) { ! if ((t = m_get(M_WAIT, MT_FTABLE)) == NULL) goto dropfrag; --- 302,304 ---- if (fp == 0) { ! if ((t = m_get(M_DONTWAIT, MT_FTABLE)) == NULL) goto dropfrag; *************** *** 490,491 **** --- 490,492 ---- + extern struct in_ifaddr *ifptoia(); struct in_ifaddr *ip_rtaddr(); *************** *** 595,597 **** break; ! bcopy((caddr_t)(cp + off), (caddr_t)&ipaddr.sin_addr, sizeof(ipaddr.sin_addr)); --- 596,598 ---- break; ! bcopy((caddr_t)(&ip->ip_dst), (caddr_t)&ipaddr.sin_addr, sizeof(ipaddr.sin_addr)); *************** *** 602,604 **** type = ICMP_UNREACH; ! code = ICMP_UNREACH_SRCFAIL; goto bad; --- 603,605 ---- type = ICMP_UNREACH; ! code = ICMP_UNREACH_HOST; goto bad; *************** *** 620,622 **** } ! sin = (struct in_addr *)(cp+cp[IPOPT_OFFSET]-1); switch (ipt->ipt_flg) { --- 621,623 ---- } ! sin = (struct in_addr *)(cp + ipt->ipt_ptr - 1); switch (ipt->ipt_flg) { *************** *** 630,636 **** goto bad; ! if (in_ifaddr == 0) ! goto bad; /* ??? */ ! bcopy((caddr_t)&IA_SIN(in_ifaddr)->sin_addr, (caddr_t)sin, sizeof(struct in_addr)); ! sin++; break; --- 631,636 ---- goto bad; ! ia = ifptoia(ifp); ! bcopy((caddr_t)&IA_SIN(ia)->sin_addr, (caddr_t)sin, sizeof(struct in_addr)); ! ipt->ipt_ptr += sizeof(struct in_addr); break; *************** *** 638,639 **** --- 638,642 ---- case IPOPT_TS_PRESPEC: + if (ipt->ipt_ptr + sizeof(n_time) + + sizeof(struct in_addr) > ipt->ipt_len) + goto bad; bcopy((caddr_t)sin, (caddr_t)&ipaddr.sin_addr, *************** *** 642,646 **** continue; - if (ipt->ipt_ptr + sizeof(n_time) + - sizeof(struct in_addr) > ipt->ipt_len) - goto bad; ipt->ipt_ptr += sizeof(struct in_addr); --- 645,646 ---- *************** *** 652,654 **** ntime = iptime(); ! bcopy((caddr_t)&ntime, (caddr_t)sin, sizeof(n_time)); ipt->ipt_ptr += sizeof(n_time); --- 652,655 ---- ntime = iptime(); ! bcopy((caddr_t)&ntime, (caddr_t)cp + ipt->ipt_ptr - 1, ! sizeof(n_time)); ipt->ipt_ptr += sizeof(n_time); *************** *** 731,733 **** return ((struct mbuf *)0); ! m = m_get(M_WAIT, MT_SOOPTS); m->m_len = ip_nhops * sizeof(struct in_addr) + IPOPT_OFFSET + 1 + 1; --- 732,736 ---- return ((struct mbuf *)0); ! m = m_get(M_DONTWAIT, MT_SOOPTS); ! if (m == 0) ! return ((struct mbuf *)0); m->m_len = ip_nhops * sizeof(struct in_addr) + IPOPT_OFFSET + 1 + 1; *************** *** 841,843 **** } ! if (ip->ip_ttl < IPTTLDEC) { type = ICMP_TIMXCEED, code = ICMP_TIMXCEED_INTRANS; --- 844,846 ---- } ! if (ip->ip_ttl <= IPTTLDEC) { type = ICMP_TIMXCEED, code = ICMP_TIMXCEED_INTRANS; *************** *** 870,873 **** --- 873,881 ---- * and if packet was not source routed (or has any options). + * Also, don't send redirect if forwarding using a default route + * or a route modfied by a redirect. */ + #define satosin(sa) ((struct sockaddr_in *)(sa)) if (ipforward_rt.ro_rt && ipforward_rt.ro_rt->rt_ifp == ifp && + (ipforward_rt.ro_rt->rt_flags & RTF_DYNAMIC) == 0 && + satosin(&ipforward_rt.ro_rt->rt_dst)->sin_addr.s_addr != 0 && ipsendredirects && ip->ip_hl == (sizeof(struct ip) >> 2)) { *************** *** 874,876 **** struct in_ifaddr *ia; - extern struct in_ifaddr *ifptoia(); u_long src = ntohl(ip->ip_src.s_addr); --- 882,883 ---- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709142329.AA07166@okeeffe.Berkeley.EDU] <1987091415295500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels) Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8709142329.AA07166@okeeffe.Berkeley.EDU> Date: Mon, 14-Sep-87 19:29:55 EDT Article-I.D.: okeeffe.8709142329.AA07166 Posted: Mon Sep 14 19:29:55 1987 Date-Received: Wed, 16-Sep-87 01:20:22 EDT References: <8709141556.AA00477@mercury.mitre.org> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 On the contrary, 4.2BSD never forwarded IP options. IP options were updated if necesssary (not necessarily correctly), stripped from the packet, then freed in ip_output without inserting them back into the packet. (I don't remember that the typo in ip_stripoptions actually crashed the machine, but it obviously wasn't right.) Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709142357.AA06633@ucbvax.Berkeley.EDU] <1987091415493500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BUDDENBERGRA@A.ISI.EDU (Rex Buddenberg) Newsgroups: comp.protocols.tcp-ip Subject: User chargeback issues Message-ID: <8709142357.AA06633@ucbvax.Berkeley.EDU> Date: Mon, 14-Sep-87 19:49:35 EDT Article-I.D.: ucbvax.8709142357.AA06633 Posted: Mon Sep 14 19:49:35 1987 Date-Received: Wed, 16-Sep-87 01:22:59 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 58 The subject of user chargeback has some economic overtones that may tend to be overlooked if we don't bring them up. Since we are in this business, on this net for 1) improving national security, 2) propagating networks to make money or 3) both, it is appropriate to look beyond the technical issues. Most communications facilities: Autodin, Autovon, FTS, are provided to the user at no perceived cost -- the 'user' charges are generally paid for at the headquarters level. At the unit level, they appear as 'free goods'. In the past, decentralizing of user charges was either not possible or didn't fit 'the way we've always done it'. This results in an unconstrained Parkinson's Law effect where usage expands to fill the capacity available. Take a look at the Navy's satellite bandwidth, the federal government's phone usage, ... for examples -- they are two-blocked. So what happens if we add user chargeback? Communications services compete for an organization's resources just like any other requirement. Incentive for rational, balanced budgeting of resources. OK so far, but there are a couple hidden gotchas. 1. What are we trying to do with DDN? If we want to make a single large internet to handle all data traffic, a user chargeback, or threat of one, is a strong inhibition to defer taking the plunge. We have private nets, continued Autodin usage, ad hoc dial-ups, etc proliferating because MilNet usage appears more expensive -- to the user. If we want DDN to proliferate, the user chargeback probably ought to be subsidized by appropriation to DCA as it is now. The extremes are a) full subsidization by DCA, like now -- provide network as a free good in order to gain market share from Autodin et al, b) full user chargeback making the service user bear full costs. Neither extreme is good, what we need is a balance somewhere between. 2. User chargebacks encourage skimming. Consider the post office; Uncle's PO, including the APOs and FPOs, delivers worldwide. I got mail through the system in the Antarctic and on Iwo Jima. Can't say that much for Federal Express or UPS. The commercial competition within CONUS takes the lucrative market and leaves Uncle with the more expensive portion of the system -- the overseas requirements. These routes are necessary, and the cost for maintaining them now goes up because the lucrative routes can't subsidize them and because we lose economies of scale. The DDN analogues are the overseas routes and classified service. Both are likely to remain exempt from the user chargeback scheme, at least at first. This is likely to result in a lot of users buying commercial network connectivity for CONUS traffic and DCA being stuck for the overseas and classified service, which will now become more expensive. 3. The final gotcha is that user chargeback needs to be implemented in a way that doesn't open the door to traffic analysis. Even if we don't chargeback to users, the data flow info is useful -- to Ivan as well as the network managers. I've been in law enforcement long enough to know how valuble telephone tolls are in tracking a smuggler and his activities -- let's not set ourselves up. Rex Buddenberg ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091415493501> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Mon 14 Sep 87 16:50:11-PDT Date: 14 Sep 1987 19:49:35 EDT Subject: User chargeback issues From: Rex Buddenberg To: tcp-ip@SRI-NIC.ARPA cc: BUDDENBERGRA@A.ISI.EDU The subject of user chargeback has some economic overtones that may tend to be overlooked if we don't bring them up. Since we are in this business, on this net for 1) improving national security, 2) propagating networks to make money or 3) both, it is appropriate to look beyond the technical issues. Most communications facilities: Autodin, Autovon, FTS, are provided to the user at no perceived cost -- the 'user' charges are generally paid for at the headquarters level. At the unit level, they appear as 'free goods'. In the past, decentralizing of user charges was either not possible or didn't fit 'the way we've always done it'. This results in an unconstrained Parkinson's Law effect where usage expands to fill the capacity available. Take a look at the Navy's satellite bandwidth, the federal government's phone usage, ... for examples -- they are two-blocked. So what happens if we add user chargeback? Communications services compete for an organization's resources just like any other requirement. Incentive for rational, balanced budgeting of resources. OK so far, but there are a couple hidden gotchas. 1. What are we trying to do with DDN? If we want to make a single large internet to handle all data traffic, a user chargeback, or threat of one, is a strong inhibition to defer taking the plunge. We have private nets, continued Autodin usage, ad hoc dial-ups, etc proliferating because MilNet usage appears more expensive -- to the user. If we want DDN to proliferate, the user chargeback probably ought to be subsidized by appropriation to DCA as it is now. The extremes are a) full subsidization by DCA, like now -- provide network as a free good in order to gain market share from Autodin et al, b) full user chargeback making the service user bear full costs. Neither extreme is good, what we need is a balance somewhere between. 2. User chargebacks encourage skimming. Consider the post office; Uncle's PO, including the APOs and FPOs, delivers worldwide. I got mail through the system in the Antarctic and on Iwo Jima. Can't say that much for Federal Express or UPS. The commercial competition within CONUS takes the lucrative market and leaves Uncle with the more expensive portion of the system -- the overseas requirements. These routes are necessary, and the cost for maintaining them now goes up because the lucrative routes can't subsidize them and because we lose economies of scale. The DDN analogues are the overseas routes and classified service. Both are likely to remain exempt from the user chargeback scheme, at least at first. This is likely to result in a lot of users buying commercial network connectivity for CONUS traffic and DCA being stuck for the overseas and classified service, which will now become more expensive. 3. The final gotcha is that user chargeback needs to be implemented in a way that doesn't open the door to traffic analysis. Even if we don't chargeback to users, the data flow info is useful -- to Ivan as well as the network managers. I've been in law enforcement long enough to know how valuble telephone tolls are in tracking a smuggler and his activities -- let's not set ourselves up. Rex Buddenberg ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [WANCHO.12334716062.BABYL@SIMTEL20.ARPA] <1987091420580000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: WANCHO@SIMTEL20.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Can of worms... Message-ID: Date: Tue, 15-Sep-87 00:58:00 EDT Article-I.D.: SIMTEL20.WANCHO.12334716062.BABYL Posted: Tue Sep 15 00:58:00 1987 Date-Received: Wed, 16-Sep-87 06:31:05 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 74 Andy, The main reason for even bringing up AHIP/AHIP-E is because that is the level this host talks to the PSN. As I understand it, the only logical place to account for host traffic is at the PSN level, and the PSN knows nothing about any protocol layers above its own - at least, it's not in that business to know. All that means is that no matter what scheme is developed for accounting of packets, any exceptions must be somehow conveyed to the PSN about each packet. If DDN X.25 already has this capability, fine. However, I doubt you will see those of us who have been running the old 1822 (a.k.a, AHIP) rushing out the door to retrofit an X.25 interface just because it doesn't and won't have this feature. In our case, we will probably just move to the backside of our gateway. Now for your specific comments, objections, and questions: 1. Because it appears that traffic through a PSN cannot be identified on a per-connection basis in order to charge for all traffic in both directions to the originating host, let's define another way: all outgoing traffic is charged to the sending host, except that traffic sent to the originating host is sent collect. It would then be up to the originating host to accept the collect message because it is keeping track of which connections it originated. The host receiving the connection already knows to send all outgoing traffic collect. Same bottom line, but without requiring the PSN to keep track of each connection. 2. How does the TCP driver know to send something collect? If it received the call, then it replies in collect mode. If it originates the call, then the only process that needs to be able to make it collect is SMTP. For large mailing list mail, we already process those messages through its own mailer and it really is trivial to add another option to the mail queue file as it's requeued. A user FTP connection is always charged to the originating host, whether normal or anonymous. 3. When reduced to the final case, all that's left in establishing a collect call is a collect SMTP connection. I would propose that the SMTP server accept the call, but refuse to receive the message based on the addressee, if that addressee is not on a special alias file. The host administrator then has control over which addressees are permitted to receive collect messages. 4. I have no sympathy for the argument that AHIP is fading and thus no changes can be made. If that's the way it is, then other courses of action become economically justifiable. However, conversion to DDN X.25 is not one of them at this time. I am painfully aware that the solutions I have proposed are worse than the problem. But, the currently proposed charging algorithm has many gaping holes in it which allow charges to be incurred which can only be controlled by dropping those services. I don't really want to do that, but I may have no choice. I'd really prefer someone in authority to declare usage-sensitive chargeback self-defeating and drop it. Finally, TAC access under the planned chargeback is simply uneconomical. I can put in more direct lines with no changes required to our accounting log mechanism at a one-time cost of much less than one month's TAC Access charges. I can buy several mainframe class computers for what those charges would be in a year. I'm sorry, but I don't believe in unchallenged pass-through charges to our users, especially when I can offer far superior services on a direct connection at no additional charge. What do I get for $0.075 per minute dialup connect time and anywhere from $0.60 to $4.00 per kilopacket on a TAC? The right to charge back to my host at the highest possible packet rate - one character per packet - at some of the lowest data rates available!!! Maybe if there was some local intelligence capable of handling some of the more popular file transfer protocols at the TAC level which can potentially increase the packet size from 100 to a 1,000-fold (and reduce the charges by the same factors) and access at 2400 and 9600 bps to reduce connect time, I might reconsider. --Frank ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091501260000> Received: from acc.arpa by SRI-NIC.ARPA with TCP; Tue 15 Sep 87 09:38:46-PDT Date: 15 Sep 87 09:26:00 PST From: Subject: Class C nets and DDN X.25 To: "tcp-ip" Reply-To: >For the record, both BBN and PANDA TOPS-20 assume that any Class C >PSN-based network will have the host number in the high order 2 bits, >and the PSN in the low order 6 bits of the fourth octet. This is the >format which we used in the good old days of NCP and 32-bit leaders, >for those of us old enough to remember that far back (am I betraying >my age????). This was fine for the original IMPS which only had four host ports. (I remember the ruggedized Honeywell 516 based IMP at UCSB which was one of the four nodes in the first incarnation of the ARPANET) But newer IMPS have many more host ports. Our in-house test IMP has 20 host ports, so we would probably recommend at least 5 bits for host number. This leaves room for a net of about 6 IMPS (reserve 0 and 7). I don't know of anyone really running a class C IMP net. We have a class C number assigned for our test IMP but haven't put it to use yet. AHIP-E could affect all this, but it may never be deployed. Art Berggreen art@acc.arpa ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091502230000> Received: from twg.arpa by SRI-NIC.ARPA with TCP; Tue 15 Sep 87 09:24:11-PDT Date: 15 Sep 87 09:23:00 PDT From: "Mike Anello" Subject: Reply: HELP: select() under sockets To: "tcp-ip" Reply-To: "Mike Anello" HELP: select() under Wollongong sockets Is it me or our sockets service?? code fragment ... set up connection on file descriptor nfd /* ********************************************** ** select test code etc. etc. etc. In response to your mail about problems with select(3W): We believe that you are incorrectly using the numfds argument in the system call. You must increase this number so that select will work on more that just stdin. Possibly using a number like 5 or 6 to be safe. Your code will only select on stdin and you probably really want to select on at least stdin, stdout, stderr, and one other file descriptor. I hope this is helpful for you. Mike Anello The Wollongong Group ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091502420000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 15 Sep 87 09:46:14-PDT Date: 15 Sep 1987 09:42-PDT Sender: CERF@A.ISI.EDU Subject: Re: user interface for urgent data. From: CERF@A.ISI.EDU To: dzoey@UMD5.UMD.EDU Cc: tcp-ip@SRI-NIC.ARPA, davidc@TERMINUS.UMD.EDU Cc: dzoey@TERMINUS.UMD.EDU Message-ID: <[A.ISI.EDU]15-Sep-87 09:42:55.CERF> In-Reply-To: <8709141456.AA04409@umd5.UMD.EDU> Joe, In the urgent daa design, it was assumed that TCP should NOT impose any kind of syntax on the data stream. Rather, the flagging of urgen data meant, roughly, "start scanning the data stream wherever you are now and go through at least to the placed marked URGENT. Process appropriately whatever you read, given that you know you are in URGENT mode until you get to byte sequence number X." It was assumed that the application using TCP would have conventions for structuring of the TCP byte stream and for interpreting what to do with urgent data indicator. Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091507083200> Received: from CC5.BBN.COM by SRI-NIC.ARPA with TCP; Tue 15 Sep 87 11:04:00-PDT To: art@ACC.ARPA cc: tcp-ip , malis@CC5.BBN.COM Subject: Re: Class C nets and DDN X.25 In-reply-to: Your message of 15 Sep 87 09:26:00 -0800. Date: Tue, 15 Sep 87 13:48:32 -0400 From: Andy Malis Art, The only addition I would like to make to your comments is that 0 is not a legal PSN number, and there is no network-layer reason to reserve PSN number 7. Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709151550.AA29860@topaz.rutgers.edu] <1987091507504800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: T1 and distant IP networks Message-ID: <8709151550.AA29860@topaz.rutgers.edu> Date: Tue, 15-Sep-87 11:50:48 EDT Article-I.D.: topaz.8709151550.AA29860 Posted: Tue Sep 15 11:50:48 1987 Date-Received: Thu, 17-Sep-87 04:40:29 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Although, if you have any VMS machines, I would seriously avoid protocol independant bridges of this nature. The older version of Wollongong TCP choke the vax in response to certain rather common broadcast messages. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091507595100> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Tue 15 Sep 87 11:51:57-PDT To: art@ACC.ARPA cc: tcp-ip , brescia@PARK-STREET.BBN.COM Subject: Re: Class C nets and AHIP (was: DDN X.25 ) In-reply-to: Your message of 15 Sep 87 09:26:00 -0800. Date: Tue, 15 Sep 87 14:39:51 -0400 From: Mike Brescia I don't know of any class C arpanets either, but we have talked about allowing the full range of 256 hosts and using only one imp. How do you find the imp number? From the NOPS at startup time. Seriously, that could be one of the range of options if the configuration of your host specified where the boundary between the host-part and the imp-part of the 8 bits available in the 'rest' part of the class C address. Thus you could have 5 bits of host to keep Art happy, and in another net, 2 bits of host. It should not be fixed over all class C arpanets. If the net grows beyond the number of hosts or imps you allow, you will have to either move the boundary, or make a transition to a class B net. /Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709151632.AA23755@ucbvax.Berkeley.EDU] <1987091508230000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mja@TWG.ARPA ("Mike Anello") Newsgroups: comp.protocols.tcp-ip Subject: Reply: HELP: select() under sockets Message-ID: <8709151632.AA23755@ucbvax.Berkeley.EDU> Date: Tue, 15-Sep-87 12:23:00 EDT Article-I.D.: ucbvax.8709151632.AA23755 Posted: Tue Sep 15 12:23:00 1987 Date-Received: Thu, 17-Sep-87 04:43:29 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "Mike Anello" Organization: The ARPA Internet Lines: 24 HELP: select() under Wollongong sockets Is it me or our sockets service?? code fragment ... set up connection on file descriptor nfd /* ********************************************** ** select test code etc. etc. etc. In response to your mail about problems with select(3W): We believe that you are incorrectly using the numfds argument in the system call. You must increase this number so that select will work on more that just stdin. Possibly using a number like 5 or 6 to be safe. Your code will only select on stdin and you probably really want to select on at least stdin, stdout, stderr, and one other file descriptor. I hope this is helpful for you. Mike Anello The Wollongong Group ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]15-Sep-87.09:42:55.CERF] <1987091508420000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: user interface for urgent data. Message-ID: <[A.ISI.EDU]15-Sep-87.09:42:55.CERF> Date: Tue, 15-Sep-87 12:42:00 EDT Article-I.D.: <[A.ISI.EDU]15-Sep-87.09:42:55.CERF> Posted: Tue Sep 15 12:42:00 1987 Date-Received: Thu, 17-Sep-87 05:58:07 EDT References: <8709141456.AA04409@umd5.UMD.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Joe, In the urgent daa design, it was assumed that TCP should NOT impose any kind of syntax on the data stream. Rather, the flagging of urgen data meant, roughly, "start scanning the data stream wherever you are now and go through at least to the placed marked URGENT. Process appropriately whatever you read, given that you know you are in URGENT mode until you get to byte sequence number X." It was assumed that the application using TCP would have conventions for structuring of the TCP byte stream and for interpreting what to do with urgent data indicator. Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709151707.AA01466@faline.bellcore.com] <1987091509071900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@FALINE.BELLCORE.COM (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: Re: FTP advisory messages Message-ID: <8709151707.AA01466@faline.bellcore.com> Date: Tue, 15-Sep-87 13:07:19 EDT Article-I.D.: faline.8709151707.AA01466 Posted: Tue Sep 15 13:07:19 1987 Date-Received: Thu, 17-Sep-87 04:53:17 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 3 Thanks, Ron, yours sounds like a good idea. I'll do it that way. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709151707.AA02244@topaz.rutgers.edu] <1987091509075400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@topaz.rutgers.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: FTP advisory messages Message-ID: <8709151707.AA02244@topaz.rutgers.edu> Date: Tue, 15-Sep-87 13:07:54 EDT Article-I.D.: topaz.8709151707.AA02244 Posted: Tue Sep 15 13:07:54 1987 Date-Received: Thu, 17-Sep-87 04:45:31 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 DO NOT ADD 0XX CLASS MESSAGES. They don't exist and some machines sent them in the past which causes the sequencing of all future replies to get messed up. The best bet is for the SERVER to just use different text to the 150 message that is printed just before the transfer (UNIX usually places the file name and the size of the file in bytes here). You can make it say something like 150 Starting "foo.bin" IN ASCII MODE -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709151713.AA02514@topaz.rutgers.edu] <1987091509132200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@topaz.rutgers.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Can of worms... Message-ID: <8709151713.AA02514@topaz.rutgers.edu> Date: Tue, 15-Sep-87 13:13:22 EDT Article-I.D.: topaz.8709151713.AA02514 Posted: Tue Sep 15 13:13:22 1987 Date-Received: Thu, 17-Sep-87 04:55:28 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Of course Frank, the DDN is mandated for use instead of putting these cheaper (and possibly better) leased circuits through. Of course, the same people have been insisting we use FTS rather than the cheaper WATS as well. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709151648.AA24217@ucbvax.Berkeley.EDU] <1987091509260000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: art@ACC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Class C nets and DDN X.25 Message-ID: <8709151648.AA24217@ucbvax.Berkeley.EDU> Date: Tue, 15-Sep-87 13:26:00 EDT Article-I.D.: ucbvax.8709151648.AA24217 Posted: Tue Sep 15 13:26:00 1987 Date-Received: Thu, 17-Sep-87 04:45:14 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 24 >For the record, both BBN and PANDA TOPS-20 assume that any Class C >PSN-based network will have the host number in the high order 2 bits, >and the PSN in the low order 6 bits of the fourth octet. This is the >format which we used in the good old days of NCP and 32-bit leaders, >for those of us old enough to remember that far back (am I betraying >my age????). This was fine for the original IMPS which only had four host ports. (I remember the ruggedized Honeywell 516 based IMP at UCSB which was one of the four nodes in the first incarnation of the ARPANET) But newer IMPS have many more host ports. Our in-house test IMP has 20 host ports, so we would probably recommend at least 5 bits for host number. This leaves room for a net of about 6 IMPS (reserve 0 and 7). I don't know of anyone really running a class C IMP net. We have a class C number assigned for our test IMP but haven't put it to use yet. AHIP-E could affect all this, but it may never be deployed. Art Berggreen art@acc.arpa ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709151811.AA25807@ucbvax.Berkeley.EDU] <1987091510145500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: malis@CC5.BBN.COM (Andy Malis) Newsgroups: comp.protocols.tcp-ip Subject: Re: Class C nets and DDN X.25 Message-ID: <8709151811.AA25807@ucbvax.Berkeley.EDU> Date: Tue, 15-Sep-87 14:14:55 EDT Article-I.D.: ucbvax.8709151811.AA25807 Posted: Tue Sep 15 14:14:55 1987 Date-Received: Thu, 17-Sep-87 05:03:56 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Art, The only addition I would like to make to your comments is that 0 is not a legal PSN number, and there is no network-layer reason to reserve PSN number 7. Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709151847.AA11999@opal.berkeley.edu] <1987091510465400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: minshall@OPAL.BERKELEY.EDU Newsgroups: comp.protocols.tcp-ip Subject: tn3270 availability Message-ID: <8709151847.AA11999@opal.berkeley.edu> Date: Tue, 15-Sep-87 14:46:54 EDT Article-I.D.: opal.8709151847.AA11999 Posted: Tue Sep 15 14:46:54 1987 Date-Received: Thu, 17-Sep-87 05:57:33 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 There is a new procedure (previously hinted at) for distributing tn3270 by mail. The current procedure for arpanet access (via anonymous ftp) remains in place. To receive a copy of tn3270 by mail, send a check for $100.00 (US), along with a note indicating your desire to receive the tn3270 diskette, to: Campus Software Office 295 Evans Hall University of California Berkeley, California 94720 USA You will receive, in exchange, an AT style (1.2MB) diskette with the tn3270 source (in tar format). For your $100.00 (US), you have unlimited redistribution rights (for both the source and any binaries generated). I encourage people to use this path to acquire tn3270. One advantage of this path is that you get on "the list". This list should allow you to receive updates and announcements. From our side, the advantage is having some handle on the use of tn3270. Sincerely, Greg Minshall ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709151912.AA27133@ucbvax.Berkeley.EDU] <1987091511215700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@PARK-STREET.BBN.COM (Mike Brescia) Newsgroups: comp.protocols.tcp-ip Subject: Re: Class C nets and AHIP (was: DDN X.25 ) Message-ID: <8709151912.AA27133@ucbvax.Berkeley.EDU> Date: Tue, 15-Sep-87 15:21:57 EDT Article-I.D.: ucbvax.8709151912.AA27133 Posted: Tue Sep 15 15:21:57 1987 Date-Received: Thu, 17-Sep-87 05:57:44 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 I don't know of any class C arpanets either, but we have talked about allowing the full range of 256 hosts and using only one imp. How do you find the imp number? From the NOPS at startup time. Seriously, that could be one of the range of options if the configuration of your host specified where the boundary between the host-part and the imp-part of the 8 bits available in the 'rest' part of the class C address. Thus you could have 5 bits of host to keep Art happy, and in another net, 2 bits of host. It should not be fixed over all class C arpanets. If the net grows beyond the number of hosts or imps you allow, you will have to either move the boundary, or make a transition to a class B net. /Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709151941.AA09356@beno.CSS.GOV] <1987091511411300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rick@SEISMO.CSS.GOV (Rick Adams) Newsgroups: comp.protocols.tcp-ip Subject: Re: FTP advisory messages Message-ID: <8709151941.AA09356@beno.CSS.GOV> Date: Tue, 15-Sep-87 15:41:13 EDT Article-I.D.: beno.8709151941.AA09356 Posted: Tue Sep 15 15:41:13 1987 Date-Received: Thu, 17-Sep-87 06:16:22 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 ftp contains a "SITE" word that is largely unused. It would be really nice if most implementations agreed on what came after the SITE word. E.g. It would be really nice to have the user mode ftp program automatically send "SITE UNIX" (or something along that line) and the ftp server on the other machine return success or failure. Then, if the user ftp got success as an answer, it could automagically set the type to image. If it got back anything but successful, it would do nothing, so no harm would be done. I actually implemented this a few years ago. There was one major problem with it. The TOPS-20 ftp servers always returned success to ANY SITE command. Obviously, this screwed up things royally. I was never successful in getting anyone to admit that the TOPS-20 was broken and to fix it. It's a pity that SITE can't be used. It work work wonderfully in this particular case. ---rick ----MESSAGE-END---- ----MESSAGE-BEGIN---- [358@palladium.UUCP] <1987091511511500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gkenley@palladium.UUCP Newsgroups: comp.sources.wanted,comp.protocols.tcp-ip Subject: Public Domain TCP/IP Message-ID: <358@palladium.UUCP> Date: Tue, 15-Sep-87 15:51:15 EDT Article-I.D.: palladiu.358 Posted: Tue Sep 15 15:51:15 1987 Date-Received: Sat, 19-Sep-87 07:59:29 EDT Organization: Palladium Data Systems, Marlboro MA Lines: 11 Keywords: TCP/IP CMC MVME350 I had been told by someone from pSOS (Real time romable OS) that a public domain implementation of TCP/IP existed for a CMC Ethernet board (which is identical to MVME350 motorola board - 68000 with AMD7990). He told me to contact John Pope of Aehr Tess in California. When I called Aehr Tess told me that he no longer was there and would not give out his forwarding address or number. We needed something that simply worked on the MVME350 board just to bootstrap ourselves. Maybe John is out there somewhere. Greg Kenley Palladium Data Sytems, Inc. "Home of the DataTub" ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091513040000> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Tue 15 Sep 87 16:06:29-PDT Received: from UCIVMSA.BITNET by wiscvm.wisc.edu ; Tue, 15 Sep 87 18:06:22 CDT Date: 15 SEP 87 16:04-SYS From: DHWalker%UCIVMSA.BITNET@wiscvm.wisc.edu To: TCP-IP@SRI-NIC.ARPA Subject: Connecting DECnet routers over IP X-Original_To: tcp-ip%SRI-NIC.ARPA@orion X-Routing: SMTPUSER @ WISCVM Received: from ORION by UCICP6 with PMDFs; 15 Sep 1987 15:53:12 Received: from localhost by orion.cf.uci.edu id a018460; 15 Sep 87 15:47 PDT Date: Tue, 15 Sep 87 15:47:17 -0700 From: David Walker I know this has been hashed over many times, but I haven't seen it quite like this, so here goes... Has anyone have a way to use TCP (UDP?) to connect two DECnet routing nodes? It would be (I think) an ideal way to provide DECnet connectivity for people in an IP environment. The DECnet people in one subnet can designate one of their systems as one of these routers to communicate with DECnet people in other subnets. David Walker Network Services Manager University of CA, Irvine ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709151611.aa27463@note.nsf.gov] <1987091514050400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: steve@NOTE.NSF.GOV Newsgroups: comp.protocols.tcp-ip Subject: Re: User chargeback issues Message-ID: <8709151611.aa27463@note.nsf.gov> Date: Tue, 15-Sep-87 18:05:04 EDT Article-I.D.: note.8709151611.aa27463 Posted: Tue Sep 15 18:05:04 1987 Date-Received: Thu, 17-Sep-87 06:30:20 EDT References: <8709151005.aa29600@SMOKE.BRL.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 3. The final gotcha is that user chargeback needs to be implemented in a way that doesn't open the door to traffic analysis. Even if we don't chargeback to users, the data flow info is useful -- to Ivan as well as the network managers. I've been in law enforcement long enough to know how valuble telephone tolls are in tracking a smuggler and his activities -- let's not set ourselves up. Get real. The door is already open to traffic analysis, and if (110 dB rattle of saber) "Ivan" really cares, he's already doing it. Chargeback is a totally orthogonal issue. -s ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709152311.AA02230@ucbvax.Berkeley.EDU] <1987091516292900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DHWalker@UCIVMSA.BITNET Newsgroups: comp.protocols.tcp-ip Subject: Connecting DECnet routers over IP Message-ID: <8709152311.AA02230@ucbvax.Berkeley.EDU> Date: Tue, 15-Sep-87 20:29:29 EDT Article-I.D.: ucbvax.8709152311.AA02230 Posted: Tue Sep 15 20:29:29 1987 Date-Received: Fri, 18-Sep-87 01:06:19 EDT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Received: from ORION by UCICP6 with PMDFs; 15 Sep 1987 15:53:12 Received: from localhost by orion.cf.uci.edu id a018460; 15 Sep 87 15:47 PDT Date: Tue, 15 Sep 87 15:47:17 -0700 From: David Walker I know this has been hashed over many times, but I haven't seen it quite like this, so here goes... Has anyone have a way to use TCP (UDP?) to connect two DECnet routing nodes? It would be (I think) an ideal way to provide DECnet connectivity for people in an IP environment. The DECnet people in one subnet can designate one of their systems as one of these routers to communicate with DECnet people in other subnets. David Walker Network Services Manager University of CA, Irvine ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709160818.AA13511@columbia.edu] <1987091600184800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: chris@COLUMBIA.EDU (Chris Maio) Newsgroups: comp.protocols.tcp-ip Subject: Re: FTP advisory messages Message-ID: <8709160818.AA13511@columbia.edu> Date: Wed, 16-Sep-87 04:18:48 EDT Article-I.D.: columbia.8709160818.AA13511 Posted: Wed Sep 16 04:18:48 1987 Date-Received: Fri, 18-Sep-87 06:27:02 EDT References: <8709151941.AA09356@beno.CSS.GOV> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Rick, > I was never successful in getting anyone to admit that the TOPS-20 was > broken and to fix it. All the TOPS-20 FTP servers I know return a 504 failure reply to a "SITE UNIX" command (in contrast to the UNIX server, which mumbles "Please login with USER first"). On the other hand, you should really be using the SYST command instead (see RFC959). Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870916091634.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM] <1987091605160000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) Newsgroups: comp.protocols.tcp-ip Subject: Connecting DECnet routers over IP Message-ID: <870916091634.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Wed, 16-Sep-87 09:16:00 EDT Article-I.D.: KOYAANIS.870916091634.3.DCP Posted: Wed Sep 16 09:16:00 1987 Date-Received: Fri, 18-Sep-87 07:09:24 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 I don't think you want to use TCP or UDP to transport DECnet packets. Rather, you probably want to use IP for that purpose. This would make DECnet a sibling of TCP, UDP, ICMP, etc. You probably find it useful to - to get an assigned number to stick in the IP protocol field, - circulate a draft RFC to make sure several people find the functionality sufficient (such as "How do you translate DECnet addresses to IP addresses?"), and - perhaps get some prototype implementations working to find the bugs and then publish your results as an RFC. I don't know the specifics of DECnet, but I am somewhat interested in what you come up with, as many of the same issues come up with CHAOSnet. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709161502.AA17850@ucbvax.Berkeley.EDU] <1987091607031500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HANK@TAUNIVM.BITNET (Hank Nussbacher) Newsgroups: comp.protocols.tcp-ip Subject: Proteon p4200 (router) Message-ID: <8709161502.AA17850@ucbvax.Berkeley.EDU> Date: Wed, 16-Sep-87 11:03:15 EDT Article-I.D.: ucbvax.8709161502.AA17850 Posted: Wed Sep 16 11:03:15 1987 Date-Received: Fri, 18-Sep-87 07:24:10 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Hank Nussbacher Organization: The ARPA Internet Lines: 8 Can people who are currently using these boxes please send me their evaluations: I am most interested in how well it handles Tcp/Ip protocols and how transparently it passes Decnet traffic. Please reply directly to me and not to the list. Thanks, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709161553.AA23253@beno.CSS.GOV] <1987091607531700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rick@SEISMO.CSS.GOV (Rick Adams) Newsgroups: comp.protocols.tcp-ip Subject: Re: FTP advisory messages Message-ID: <8709161553.AA23253@beno.CSS.GOV> Date: Wed, 16-Sep-87 11:53:17 EDT Article-I.D.: beno.8709161553.AA23253 Posted: Wed Sep 16 11:53:17 1987 Date-Received: Sat, 19-Sep-87 00:37:40 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Great. They finally fixed it! The server used to return a 2xx response. Now all we need is for them to produce legal RFC822 date lines... ---rick ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709161702.AA02350@trantor.UMD.EDU] <1987091609020300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: louie@TRANTOR.UMD.EDU (Louis A. Mamakos) Newsgroups: comp.protocols.tcp-ip Subject: Clockwatchers beware Message-ID: <8709161702.AA02350@trantor.UMD.EDU> Date: Wed, 16-Sep-87 13:02:03 EDT Article-I.D.: trantor.8709161702.AA02350 Posted: Wed Sep 16 13:02:03 1987 Date-Received: Sat, 19-Sep-87 01:26:39 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Folks, The WWVB clock attached to UMD1.UMD.EDU aka WWVB.UMD.EDU is not currently usable, as the disk drive on that host is very unhappy. If you use the clock services of this clock with UDP/NTP or UDP/TIME, you'll be out of luck for a day or two. louie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709161807.AA21496@ucbvax.Berkeley.EDU] <1987091609515500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: TS0400@OHSTVMA.BITNET (Bob Dixon) Newsgroups: comp.protocols.tcp-ip Subject: ACC ACCES/MVS Message-ID: <8709161807.AA21496@ucbvax.Berkeley.EDU> Date: Wed, 16-Sep-87 13:51:55 EDT Article-I.D.: ucbvax.8709161807.AA21496 Posted: Wed Sep 16 13:51:55 1987 Date-Received: Sat, 19-Sep-87 01:30:03 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Ron Stoughton's information was very helpful. But I must point out how ironic the full-screen situation is. Non-IBM computers can telnet into either ACCES or KNET and get full-screen operation. Yet the 2 IBM systems cannot telnet to EACH OTHER and get full- screen operation. It would be nice if you two companies stopped the finger- pointing and solved your mutual interoperability problems. Bob Dixon Ohio State University Acknowledge-To: ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091609515501> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Wed 16 Sep 87 10:59:21-PDT Received: from OHSTVMA.BITNET by wiscvm.wisc.edu ; Wed, 16 Sep 87 12:59:27 CDT Received: by OHSTVMA (Mailer X1.23b) id 6659; Wed, 16 Sep 87 13:58:17 EDT Date: Wed, 16 Sep 87 13:51:55 EDT From: Bob Dixon Subject: ACC ACCES/MVS To: TCP-IP@SRI-NIC.ARPA Ron Stoughton's information was very helpful. But I must point out how ironic the full-screen situation is. Non-IBM computers can telnet into either ACCES or KNET and get full-screen operation. Yet the 2 IBM systems cannot telnet to EACH OTHER and get full- screen operation. It would be nice if you two companies stopped the finger- pointing and solved your mutual interoperability problems. Bob Dixon Ohio State University Acknowledge-To: ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1512@sics.se] <1987091610295500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: erikn@sics.se (Erik Nordmark) Newsgroups: comp.protocols.tcp-ip Subject: Benchmarks for high-level protocols Message-ID: <1512@sics.se> Date: Wed, 16-Sep-87 14:29:55 EDT Article-I.D.: sics.1512 Posted: Wed Sep 16 14:29:55 1987 Date-Received: Sun, 20-Sep-87 10:49:56 EDT Organization: Swedish Institute of Computer Science, Kista Lines: 28 Summary: Looking for protocol benchmarks Sender: Reply-To: erikn@sics.se (Erik Nordmark) Followup-To: Distribution: world Organization: Swedish Institute of Computer Science, Kista Keywords: benchmark performance To my knowledge the standard way of comparing protocol performance is to transfer a large file between two machines using the different protocols. My question to the net is if anybody uses more sophisticated benchmarks that take into account e.g. real-time communication, transaction-style communication, the overhead for multiple connections, the protocol's ability to handle packet loss due to the sender(s) overrunning the receiver et.c. et.c. (Pointers to any litterature on the topic are appreciated too!) If the response to this message is significant I'll summarize to the net! ------------------------------------------------------------------------- Erik Nordmark Swedish Institute of Computer Science, Box 1263, S-163 13 SPANGA, Sweden Phone: +46 8 750 79 70 Ttx: 812 61 54 SICS S Fax: +46 8 751 72 30 uucp: erikn@sics.UUCP or {seismo,mcvax}!enea!sics!erikn Domain: erikn@sics.se ------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709162008.AA24011@ucbvax.Berkeley.EDU] <1987091611475200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: A024012@RUTVM1.BITNET (Ross Patterson) Newsgroups: comp.protocols.tcp-ip Subject: Re: FTP advisory messages Message-ID: <8709162008.AA24011@ucbvax.Berkeley.EDU> Date: Wed, 16-Sep-87 15:47:52 EDT Article-I.D.: ucbvax.8709162008.AA24011 Posted: Wed Sep 16 15:47:52 1987 Date-Received: Sat, 19-Sep-87 11:42:23 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Rick, According to RFC 959, the SYST command should be used for verifying the type of server you're using. It's documented as having no parameters, and returning as the first word of the response, a system name defined in the Assigned Numbers RFC (whatever it's called this week). The SITE command is specifically intended for necessary, but non-universal, parameters. The only system I've seen that actually uses it (UCLA's IBM MVS implementation) has 20 different parameters that it accepts. It can specify the disk on which to store a file; what sort of disk it is; whether to do tab expansion, and if so, how wide; disk storage format (record lengths, etc); even that the next file sent is to be run as a batch job. My point is that any attempt to standardize the use of the SITE command is improper. If you want a standard facility, change another command or add a new one. SITE is for those systems that have other needs and/or capabilities, beyond the standards. Ross Patterson Rutgers University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091611475201> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Wed 16 Sep 87 12:58:54-PDT Received: from RUTVM1.BITNET by wiscvm.wisc.edu ; Wed, 16 Sep 87 14:58:41 CDT Received: by RUTVM1 (Mailer X1.25) id 7076; Wed, 16 Sep 87 15:58:39 EDT Date: Wed, 16 Sep 1987 15:47:52 EDT From: Ross Patterson Subject: Re: FTP advisory messages To: TCP-IP@SRI-NIC.ARPA In-Reply-To: Message of Tue, 15 Sep 87 15:41:13 EDT from Rick, According to RFC 959, the SYST command should be used for verifying the type of server you're using. It's documented as having no parameters, and returning as the first word of the response, a system name defined in the Assigned Numbers RFC (whatever it's called this week). The SITE command is specifically intended for necessary, but non-universal, parameters. The only system I've seen that actually uses it (UCLA's IBM MVS implementation) has 20 different parameters that it accepts. It can specify the disk on which to store a file; what sort of disk it is; whether to do tab expansion, and if so, how wide; disk storage format (record lengths, etc); even that the next file sent is to be run as a batch job. My point is that any attempt to standardize the use of the SITE command is improper. If you want a standard facility, change another command or add a new one. SITE is for those systems that have other needs and/or capabilities, beyond the standards. Ross Patterson Rutgers University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091613000000> Received: from ACC-SB-UNIX.ARPA by SRI-NIC.ARPA with TCP; Wed 16 Sep 87 20:00:00-PDT Received: by ACC-SB-UNIX.ARPA (5.51/4.7) id AA14858; Wed, 16 Sep 87 20:00:00 PDT Date: Wed, 16 Sep 87 20:00:00 PDT From: rms@ACC-SB-UNIX.ARPA (Ron Stoughton) Message-Id: <8709170300.AA14858@ACC-SB-UNIX.ARPA> To: tcp-ip@sri-nic.arpa Subject: Re: ACC's ACCES/MVS Cc: .@ACC-SB-UNIX.ARPA > It would be nice if you two companies stopped the finger- > pointing and solved your mutual interoperability problems. > > Bob Dixon > Ohio State University I think we're trying to do this through the TN3270 mail list which was formed to discuss such problems. I have included for the record a copy of my recent message to this list on this very same subject. I think it is self explanatory. It was in response to Bruce Craybil's rehtorical query whether the group was going to decide anything. I should also point out that the procedures for negotiating a 3270 Telnet session are not specified in any officially endorsed document. Thus we have the situation we have today. The only official record of this protocol is the two original systems which implemented it -- Wiscnet and UCLA ACP. Ron Stoughton rms@acc-sb-unix.apra > Received: by columbia-pdn (5.51/5.17) > id AA25241; Tue, 15 Sep 87 22:06:40 EDT > Received: by ACC-SB-UNIX.ARPA (5.51/4.7) > id AA02106; Tue, 15 Sep 87 19:05:53 PDT > Date: Tue, 15 Sep 87 19:05:53 PDT > From: rms@ACC-SB-UNIX.ARPA (Ron Stoughton) > Message-Id: <8709160205.AA02106@ACC-SB-UNIX.ARPA> > To: @UMD2.UMD.EDU:BRUCE@UMDD.BITNET, TN3270@terminus.UMD.EDU > Subject: Deciding SOMETHING > Status: RO > > As a vendor caught in the middle, I should probably comment. It is > ironic that during the initial flurry of messages when this list first > started up, I was out of town at a customer's site trying to find out > why we don't interoperate with another vendor's product. Even though > I think I have history on my side, and hopefully Bob Braden since it's > his code, it does the customer little good for me to beat my chest > claiming we're right. > > I certainly hope this group does decide SOMETHING, possibly starting > with what is the endorsed procedure for negotiating a full-screen > session TODAY. Since our work queue is already overflowing, my initial > vote will be cast for that which doesn't require us to change anything > (i.e., the minimal pain philosophy). However, we will comply with > whatever this group endorses. > > In the longer term, we need to decide how to support other 3270 features, > which will likely be accommodated by additional negotiations. This may > be the appropriate time to simplify the procedures. I tend to be more > of a pragmatist than a purist, so I have no objection to combining > multiple options into a single negotiation. > > Ron Stoughton > rms@acc-sb-unix.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091614290000> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Wed 16 Sep 87 07:56:37-PDT Received: from VM1.TAU.AC.IL by wiscvm.wisc.edu ; Wed, 16 Sep 87 09:56:33 CDT Received: by TAUNIVM (Mailer X1.24) id 5537; Wed, 16 Sep 87 11:01:47 IST Date: Wed, 16 Sep 87 10:59 IST From: Hank Nussbacher Subject: Proteon p4200 (router) To: Reply-To: Hank Nussbacher Can people who are currently using these boxes please send me their evaluations: I am most interested in how well it handles Tcp/Ip protocols and how transparently it passes Decnet traffic. Please reply directly to me and not to the list. Thanks, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709162045.aa02635@SEM.BRL.ARPA] <1987091616450800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mike@BRL.ARPA (Mike Muuss) Newsgroups: comp.protocols.tcp-ip Subject: Re: Multiple Internet addresses Message-ID: <8709162045.aa02635@SEM.BRL.ARPA> Date: Wed, 16-Sep-87 20:45:08 EDT Article-I.D.: SEM.8709162045.aa02635 Posted: Wed Sep 16 20:45:08 1987 Date-Received: Sat, 19-Sep-87 14:24:34 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 The strategy that we have used at BRL (implemented by J. Pistritto) for many years now is to run a simple program on each local net host (called "router") that is given a prioritized list of "default routes". The highest priority route that meets certain maximum roundtrip times (< 5 sec) and maximum packet loss rates (50%) is selected. When the highest priority route is not selected, all higher priority ones are PINGed at a slow rates (once/minute). When a higher priority path becomes acceptable again, the default route is switched back to it. No PINGs leave the local network, and the ping rate is very low. 4.3 BSD does the rest, handling redirects, etc., that the gateway issues, and reconsulting the routing tables when a TCP connection is "halfway" timed out. We have found this strategy to work very successfully. FYI -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709170359.AA04435@topaz.rutgers.edu] <1987091619594700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: T1 and distant IP networks Message-ID: <8709170359.AA04435@topaz.rutgers.edu> Date: Wed, 16-Sep-87 23:59:47 EDT Article-I.D.: topaz.8709170359.AA04435 Posted: Wed Sep 16 23:59:47 1987 Date-Received: Sat, 19-Sep-87 08:38:22 EDT References: <15347@hi.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 29 We have three situations similar to what you describe, i.e. pairs of IP networks connected by T1. We are using the following three approaches: - VAXes running Ultrix with the T1 line connected to DMR11's. Avanti T1 Mux's are used to cut down the speed, since no known DEC line controller can deal with speeds this high. This is probably the cheapest of the 3 methods, if you already have the VAXes, but also give the worst performance and has other disadvantages. - Cisco IP routers, using either Digilink T1-izers (boxes that take a vanilla 1.5Mb synchronous signal and format it for T1) or Avanti T1 muxes (for cases where we need to use the line for things other than the IP link, e.g. talking to 3270 cluster controllers at the other site). This is my preferred solution. (Of course vendors other than Cisco also make routers that would do this. You might want to talk to Proteon and U-B also.) - U-B bridges. These would also need either a T1-izer or T1 mux. These are level 2 bridges rather than level 3 routers, which have both advantages and disadvantages. (They have been discussed so often that I am not about to repeat the discussion.) The U-B bridges have worked very well, but note that you must dedicate an IBM PC or clone to boot them. (I believe the same PC can be shared for booting all U-B products.) I strongly oppose the use of this approach if the two IP networks are under different administration, and if you don't have support staff available at both ends. Junk coming from the other end can sink your network. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709170404.AA01156@okeeffe.Berkeley.EDU] <1987091620040000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: official Berkeley fix for telnetd CR-NL mapping Message-ID: <8709170404.AA01156@okeeffe.Berkeley.EDU> Date: Thu, 17-Sep-87 00:04:00 EDT Article-I.D.: okeeffe.8709170404.AA01156 Posted: Thu Sep 17 00:04:00 1987 Date-Received: Sat, 19-Sep-87 06:46:21 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 68 In order to resolve certain compatibility problems when telnet sessions are nested, 4.3BSD telnetd has been changed to translate to '\r' rather than 'n'. This circumvents problems when using a telnet client that is incapable of sending to signify a carriage return, then using telnet or tip to connect to a system that differentiates between carriage return and line feed. (See previous discussions on the tcp-ip mailing list.) This patch also fixes an error that mapped to '\r' in binary mode. It is recommended that all 4.3BSD sites change telnetd according to this patch. Mike *** /nbsd/usr/src/etc/telnetd.c Mon May 12 22:21:51 1986 --- telnetd.c Wed Sep 2 23:22:30 1987 *************** *** 13,15 **** #ifndef lint ! static char sccsid[] = "@(#)telnetd.c 5.18 (Berkeley) 5/12/86"; #endif not lint --- 13,15 ---- #ifndef lint ! static char sccsid[] = "@(#)telnetd.c 5.20 (Berkeley) 9/2/87"; #endif not lint *************** *** 573,575 **** *nfrontp++ = c; ! if (c == '\r') { if (pcc > 0 && ((*ptyip & 0377) == '\n')) { --- 573,576 ---- *nfrontp++ = c; ! /* Don't do CR-NUL if we are in binary mode */ ! if ((c == '\r') && (myopts[TELOPT_BINARY] == OPT_NO)) { if (pcc > 0 && ((*ptyip & 0377) == '\n')) { *************** *** 617,618 **** --- 618,620 ---- state = TS_DATA; + /* Strip off \n or \0 after a \r */ if ((c == 0) || (c == '\n')) { *************** *** 630,632 **** /* ! * We map \r\n ==> \n, since \r\n says * that we want to be in column 1 of the next --- 632,638 ---- /* ! * We now map \r\n ==> \r for pragmatic reasons. ! * Many client implementations send \r\n when ! * the user hits the CarriageReturn key. ! * ! * We USED to map \r\n ==> \n, since \r\n says * that we want to be in column 1 of the next *************** *** 636,644 **** */ ! if ((myopts[TELOPT_BINARY] == OPT_NO) && c == '\r') { ! if ((ncc > 0) && ('\n' == *netip)) { ! netip++; ncc--; ! c = '\n'; ! } else { ! state = TS_CR; ! } } --- 642,645 ---- */ ! if ((c == '\r') && (hisopts[TELOPT_BINARY] == OPT_NO)) { ! state = TS_CR; } ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709170606.AA08773@topaz.rutgers.edu] <1987091622060300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Connecting DECnet routers over IP Message-ID: <8709170606.AA08773@topaz.rutgers.edu> Date: Thu, 17-Sep-87 02:06:03 EDT Article-I.D.: topaz.8709170606.AA08773 Posted: Thu Sep 17 02:06:03 1987 Date-Received: Sat, 19-Sep-87 07:27:25 EDT References: <8709160707.AA04585@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 14 If someone seriously needs this, and uses Cisco IP routers, please tell me. I have an implementation of DECnet for the Cisco routers. Encapsulating DECnet in IP would be fairly easy in my implementation. However there is no obvious advantage to doing this, unless you need to send DECnet between two Ethernets that are fairly far apart. That is, if somebody at UCI wanted to talk DECnet to somebody at Rutgers, it might make sense to send DECnet over the Arpanet encapsulated in IP (though I'd probably first investigate allocating a link type for DECnet). But for two Ethernets on one campus, this probably does not make sense. In order to get a DECnet host to send you packets for forwarding, you must implement most of the DECnet routing layer. Having done so, you might as well finish it and become a real DECnet router. In that case, there's no particular reason to encapsulate DECnet in IP. You might as well route it as DECnet. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [846@idec.stc.co.uk] <1987091702205000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: howellg@idec.stc.co.uk (Gareth Howell) Newsgroups: comp.protocols.tcp-ip Subject: DDN Protocol Handbook Message-ID: <846@idec.stc.co.uk> Date: Thu, 17-Sep-87 06:20:50 EDT Article-I.D.: idec.846 Posted: Thu Sep 17 06:20:50 1987 Date-Received: Sun, 20-Sep-87 19:58:00 EDT Organization: STC Network Systems, Stevenage, Herts. UK Lines: 11 Keywords: Citation Recently I saw a reference to the DDN protocol handbook. Can anybody provide a full citation so that I can obtain a copy through our library service. Please email if possible Thanks, Gareth -- Gareth Howell G6KVK @ IO91VX ICL Network Systems, Private Networks Business Centre London Road, Stevenage, Herts, England, SG1 1YB Tel:+44 (0)438 738294 howellg%idec%ukc@mcvax.uucp, idec!howellg@seismo.CSS.GOV ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091703213800> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Wed 16 Sep 87 22:34:06-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA05518; Wed, 16 Sep 87 22:34:14 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: 17 Sep 87 03:21:38 GMT From: mangler@csvax.caltech.edu (System Mangler) Organization: California Institute of Technology Subject: domain forwarder authorization? Message-Id: <4001@cit-vax.Caltech.Edu> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa One of our uucp neighbors is applying for a domain name via the UUCP Zone Registry, and has asked us to be their official mail forwarder on the ARPAnet, i.e. the nameserver MX record for them would point to us. What authorization do we have to get from the DDN folks to be registered as the official forwarder for a domain that does not have sponsorship to connect directly to the Internet? Whom should I contact about it? Similarly, what kind of authorization is required for us to be a registered nameserver for their domain? Don Speck speck@vlsi.caltech.edu {amdahl,rutgers}!cit-vax!speck ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091704375000> Received: from Sun.COM by SRI-NIC.ARPA with TCP; Thu 17 Sep 87 11:39:23-PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-3.2) id AA03569; Thu, 17 Sep 87 11:34:48 PDT Received: from vatican.sun.com by snail.sun.com (4.0/SMI-3.2) id AA14695; Thu, 17 Sep 87 11:30:54 PDT Received: by vatican.sun.com (4.0/SMI-4.0Alpha) id AA00360; Thu, 17 Sep 87 11:37:50 PDT Date: Thu, 17 Sep 87 11:37:50 PDT From: jlp@Sun.COM (John Pope) Message-Id: <8709171837.AA00360@vatican.sun.com> Newsgroups: comp.sources.wanted,comp.protocols.tcp-ip Subject: Re: Public Domain TCP/IP References: <358@palladium.UUCP> Reply-To: jlp@Sun.COM (John Pope) Organization: Sun Microsystems, Mountain View Keywords: TCP/IP CMC MVME350 To: tcp-ip@sri-nic.ARPA In article <358@palladium.UUCP> gkenley@palladium.UUCP (Greg Kenley) writes: >I had been told by someone from pSOS (Real time romable OS) that a public >domain implementation of TCP/IP existed for a CMC Ethernet board (which is >identical to MVME350 motorola board - 68000 with AMD7990). He told me >to contact John Pope of Aehr Tess in California. When I called Aehr Tess >told me that he no longer was there and would not give out his forwarding >address or number. We needed something that simply worked on the MVME350 >board just to bootstrap ourselves. Maybe John is out there somewhere. > >Greg Kenley >Palladium Data Sytems, Inc. >"Home of the DataTub" Yes, I am out here. Unfortunately, I don't think I have what you're looking for. The PD software in question was a Unix driver modified to run under pSOS, not an implementation of TCP/IP. The TCP/IP we were using at AEHR Test was the one supplied by CMC, which works just fine. P.S. What's a DataTub?? John Pope Sun Microsystems, Inc. jlp@sun.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1954@encore.UUCP] <1987091707334200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: loverso@encore.UUCP (John LoVerso) Newsgroups: comp.protocols.tcp-ip Subject: Re: IP options Message-ID: <1954@encore.UUCP> Date: Thu, 17-Sep-87 11:33:42 EDT Article-I.D.: encore.1954 Posted: Thu Sep 17 11:33:42 1987 Date-Received: Sat, 19-Sep-87 15:00:08 EDT References: <423@root44.co.uk> <8709092006.AA09597@okeeffe.Berkeley.EDU> <6211@sgi.SGI.COM> Reply-To: loverso@encore.UUCP (John LoVerso) Organization: Encore Computer Corp, Marlboro, MA Lines: 69 Summary: RTF_MODIFIED In article <6211@sgi.SGI.COM> vjs@rhyolite.SGI.COM (Vernon Schryver) writes: > I have been faithfully following the 4.3 fixes posted here and in the > 'official' news group. However, RTF_MODIFIED does not seem to be > defined in my source. To my knowledge, they've never been released outside of Berkeley other than in the Tahoe-Beta release of 4.3BSD. In there, RTF_MODIFIED is defined to mean the route came in via a redirect. Here are the diffs to net/route.[ch]. With all the various versions of the 4.3 TCP/IP code I've seen, this is just about all that I've ever seen changed in net/. BTW, I'm only posting this since I haven't seen a reply from Mike Karels yet, and without this, his ip_input.c changes aren't much good. John *** /source/BSD4.3/sys/net/route.h Thu Jun 5 02:43:05 1986 --- route.h Thu Jan 15 18:09:44 1987 *************** *** 4,8 **** * specifies the terms and conditions for redistribution. * ! * @(#)route.h 7.1 (Berkeley) 6/4/86 */ --- 4,8 ---- * specifies the terms and conditions for redistribution. * ! * @(#)route.h 7.2 (Berkeley) 1/15/87 */ *************** *** 46,49 **** --- 46,50 ---- #define RTF_HOST 0x4 /* host entry (net otherwise) */ #define RTF_DYNAMIC 0x10 /* created dynamically (by redirect) */ + #define RTF_MODIFIED 0x20 /* modified dynamically (by redirect) */ /* *** /source/BSD4.3/sys/net/route.c Thu Jun 5 02:42:47 1986 --- route.c Thu Jan 15 18:09:44 1987 *************** *** 4,8 **** * specifies the terms and conditions for redistribution. * ! * @(#)route.c 7.1 (Berkeley) 6/4/86 */ --- 4,8 ---- * specifies the terms and conditions for redistribution. * ! * @(#)route.c 7.2 (Berkeley) 1/15/87 */ *************** *** 176,181 **** */ rt->rt_gateway = *gateway; } - rtstat.rts_newgateway++; } else rtstat.rts_badredirect++; --- 176,182 ---- */ rt->rt_gateway = *gateway; + rt->rt_flags |= RTF_MODIFIED; + rtstat.rts_newgateway++; } } else rtstat.rts_badredirect++; ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091707395800> Received: from devvax.TN.CORNELL.EDU ([128.84.253.200]) by SRI-NIC.ARPA with TCP; Thu 17 Sep 87 08:45:17-PDT Date: Thu, 17 Sep 87 11:39:58 EDT From: fedor@devvax.tn.cornell.edu (Mark Fedor) Received: by devvax.TN.CORNELL.EDU (5.54/1.3-Cornell-Theory-Center) id AA22352; Thu, 17 Sep 87 11:39:58 EDT Message-Id: <8709171539.AA22352@devvax.TN.CORNELL.EDU> To: mike@brl.arpa, narten@purdue.edu Subject: Re: Multiple Internet addresses Cc: ietf@gateway.mitre.org, tcp-ip@sri-nic.arpa >Date: Wed, 16 Sep 87 20:45:08 EDT >From: Mike Muuss >Subject: Re: Multiple Internet addresses > >The strategy that we have used at BRL (implemented by J. Pistritto) >for many years now is to run a simple program on each local net host >(called "router") that is given a prioritized list of "default routes". >The highest priority route that meets certain maximum roundtrip times (< >5 sec) and maximum packet loss rates (50%) is selected. When the >highest priority route is not selected, all higher priority ones are >PINGed at a slow rates (once/minute). When a higher priority path >becomes acceptable again, the default route is switched back to it. >No PINGs leave the local network, and the ping rate is very low. > >4.3 BSD does the rest, handling redirects, etc., that the gateway issues, >and reconsulting the routing tables when a TCP connection is "halfway" >timed out. > >We have found this strategy to work very successfully. > FYI > -Mike > Mike, This sounds interesting, but your letter left me with a question on "router". Since 4.3BSD does not time out/delete routes learned via a redirect from the kernel, does the "router" program delete a redirect-learned route if the gateway for that route goes away? Hope this is clear enough... Mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1753@cadovax.UUCP] <1987091709510500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: carlf@cadovax.UUCP Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Networking Delays Message-ID: <1753@cadovax.UUCP> Date: Thu, 17-Sep-87 13:51:05 EDT Article-I.D.: cadovax.1753 Posted: Thu Sep 17 13:51:05 1987 Date-Received: Sat, 19-Sep-87 17:04:32 EDT Expires: Thu, 1-Oct-87 00:00:00 EDT Reply-To: carlf@cadovax.UUCP (Carl Friedman) Distribution: world Organization: Contel Business Systems, Torrance, CA Lines: 6 Keywords: networks, LANs Does anyone have information regarding the delays caused by software in each of the OSI layers over a 10 mb Ethernet LAN? I am also interested in what delay would be experienced if TCP/IP were used instead of OSI Layers 3 and 4. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [28325@sun.uucp] <1987091710401400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jlp@vatican.UUCP Newsgroups: comp.sources.wanted,comp.protocols.tcp-ip Subject: Re: Public Domain TCP/IP Message-ID: <28325@sun.uucp> Date: Thu, 17-Sep-87 14:40:14 EDT Article-I.D.: sun.28325 Posted: Thu Sep 17 14:40:14 1987 Date-Received: Sat, 19-Sep-87 09:48:07 EDT References: <358@palladium.UUCP> Sender: news@sun.uucp Reply-To: jlp@sun.UUCP (John Pope) Organization: Sun Microsystems, Mountain View Lines: 24 Keywords: TCP/IP CMC MVME350 In article <358@palladium.UUCP> gkenley@palladium.UUCP (Greg Kenley) writes: >I had been told by someone from pSOS (Real time romable OS) that a public >domain implementation of TCP/IP existed for a CMC Ethernet board (which is >identical to MVME350 motorola board - 68000 with AMD7990). He told me >to contact John Pope of Aehr Tess in California. When I called Aehr Tess >told me that he no longer was there and would not give out his forwarding >address or number. We needed something that simply worked on the MVME350 >board just to bootstrap ourselves. Maybe John is out there somewhere. > >Greg Kenley >Palladium Data Sytems, Inc. >"Home of the DataTub" Yes, I am out here. Unfortunately, I don't think I have what you're looking for. The PD software in question was a Unix driver modified to run under pSOS, not an implementation of TCP/IP. The TCP/IP we were using at AEHR Test was the one supplied by CMC, which works just fine. P.S. What's a DataTub?? John Pope Sun Microsystems, Inc. jlp@sun.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709172107.AA16664@beno.CSS.GOV] <1987091713074000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rick@SEISMO.CSS.GOV (Rick Adams) Newsgroups: comp.protocols.tcp-ip Subject: Re: FTP advisory messages Message-ID: <8709172107.AA16664@beno.CSS.GOV> Date: Thu, 17-Sep-87 17:07:40 EDT Article-I.D.: beno.8709172107.AA16664 Posted: Thu Sep 17 17:07:40 1987 Date-Received: Sat, 19-Sep-87 15:48:44 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 The SYST command looks cute but in the real world is useless. While I suppose that if you get MVS or VMS or TOPS-20 back from the SYST command it might be useful, if it returns "UNIX" then you really haven't gained anything. The wonderful thing about UNIX is that it runs on almost any hardware. What I really want to know in this example is the packing (and possibly byte ordering) of characters in a word. I don't believe that all Unix implementations are 8 bits = 1 character = 1 byte. I think the C/70 has a 9 bit byte or something. It runs Unix (I don't have my manuals with me, but you get the idea) If SITE works (and I'm told that it does finally work), then you could do something like "SITE 8BITBYTES" and decide whether to go into binary mode based on that. SYST might be useful, but since its constrained to returning official system types, it just doesn't cut it for UNIX. --rick ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091713211600> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sat 19 Sep 87 04:39:16-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA03062; Sat, 19 Sep 87 04:34:53 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: 17 Sep 87 13:21:16 GMT From: mcvax!enea!ttds!draken!sics!erikn@seismo.css.gov (Erik Nordmark) Organization: Swedish Institute of Computer Science, Kista Subject: Benchmarks for high-level protocols Message-Id: <1514@sics.se> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa Sender: Reply-To: erikn@sics.se (Erik Nordmark) Followup-To: Distribution: world Organization: Swedish Institute of Computer Science, Kista Keywords: benchmark performance To my knowledge the standard way of comparing protocol performance is to transfer a large file between two machines using the different protocols. My question to the net is if anybody uses more sophisticated benchmarks that take into account e.g. real-time communication, transaction-style communication, the overhead for multiple connections, the protocol's ability to handle packet loss due to the sender(s) overrunning the receiver et.c. et.c. (Pointers to any litterature on the topic are appreciated too!) If the response to this message is significant I'll summarize to the net! ------------------------------------------------------------------------- Erik Nordmark Swedish Institute of Computer Science, Box 1263, S-163 13 SPANGA, Sweden Phone: +46 8 750 79 70 Ttx: 812 61 54 SICS S Fax: +46 8 751 72 30 uucp: erikn@sics.UUCP or {seismo,mcvax}!enea!sics!erikn Domain: erikn@sics.se ------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091714554400> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Thu 17 Sep 87 20:10:48-PDT To: William Westfield cc: tcp-ip@SRI-NIC.ARPA, brescia@PARK-STREET.BBN.COM Subject: Re: Question about IP options In-reply-to: Your message of Thu, 17 Sep 87 17:53:55 -0700. <12335457880.12.BILLW@MATHOM.CISCO.COM> Date: Thu, 17 Sep 87 21:35:44 -0400 From: Mike Brescia Bill, When I talked about processing IP options only if the packet was addressed to the gateway, that was historically accurate for the LSI11 core gateways, which did not implement record route, timestamping or security options. Because of the extra overhead of doing a complete scan of the IP options at every gateway hop, I propose, only slightly tongue-in-cheek, that we extend the IP header by 8 (16? 32?) bits for a flag word indicating that certain options are present and should be scanned. Use bit[i] to indicate the presence of an option whose value is "i". Gateways which do not handle security, for example, can rapidly dispose of (oops, forward :-) those packets with only the security option bit on. This is an extension of an earlier idea (source unknown) which used a single bit in the IP header to declare the presence of options which needed processing at every gateway. Note: if you have any flames about the specifics of the proposal, I doubt that I will answer them. I did want to get in a bid for faster handling of packets. Maybe I am still too concerned with 'efficiency'. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709171941.aa25446@SMOKE.BRL.ARPA] <1987091715412000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: phil@BRL.ARPA (Phil Dykstra) Newsgroups: comp.protocols.tcp-ip Subject: Re: Multiple Internet addresses Message-ID: <8709171941.aa25446@SMOKE.BRL.ARPA> Date: Thu, 17-Sep-87 19:41:20 EDT Article-I.D.: SMOKE.8709171941.aa25446 Posted: Thu Sep 17 19:41:20 1987 Date-Received: Sun, 20-Sep-87 04:52:20 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Mark, You guessed correctly. When the current default route goes away "router" crafts up a new default entry, removes the old one, and then removes any references to the old default (letting the kernal rebind to the new one). The end result is that your applications can usually keep on talking without realizing that their route has been changed. - Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709171947.aa25490@SMOKE.BRL.ARPA] <1987091715473000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: phil@BRL.ARPA (Phil Dykstra) Newsgroups: comp.protocols.tcp-ip Subject: Re: Multiple Internet addresses Message-ID: <8709171947.aa25490@SMOKE.BRL.ARPA> Date: Thu, 17-Sep-87 19:47:30 EDT Article-I.D.: SMOKE.8709171947.aa25490 Posted: Thu Sep 17 19:47:30 1987 Date-Received: Sun, 20-Sep-87 05:04:00 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Mark, You guessed correctly. When the current default route goes away, "router" crafts up a new default, deletes the old one, and then removes any references to the old default (letting the kernel rebind them to the new one). The end result is that your applications can usually keep on talking without realizing that their route has changed. - Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709172351.AA10074@bu-cs.BU.EDU] <1987091715513300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bzs@BU-CS.BU.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: FTP advisory messages Message-ID: <8709172351.AA10074@bu-cs.BU.EDU> Date: Thu, 17-Sep-87 19:51:33 EDT Article-I.D.: bu-cs.8709172351.AA10074 Posted: Thu Sep 17 19:51:33 1987 Date-Received: Sat, 19-Sep-87 10:16:02 EDT References: <8709172107.AA16664@beno.CSS.GOV> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 40 From: rick@seismo.CSS.GOV (Rick Adams) >The wonderful thing about UNIX is that it runs on almost any hardware. >What I really want to know in this example is the packing (and >possibly byte ordering) of characters in a word. I don't believe that >all Unix implementations are 8 bits = 1 character = 1 byte. I think the >C/70 has a 9 bit byte or something. It runs Unix (I don't have my manuals >with me, but you get the idea) > >If SITE works (and I'm told that it does finally work), then you could >do something like "SITE 8BITBYTES" and decide whether to go into binary >mode based on that. It's not even obvious that the particular operating system was ever germaine, that may have been a false start (as you seem to point out in your example.) An image file between a VAX/VMS and VAX/UNIX system will work in image mode as will a 68K and IBM370, something more abstract needs to be developed to cover the cases. Perhaps an asymmetrical psuedo-bitstring who's bit order and length can be used to infer the architecture? Something like: VAX,NS32k: "10010110 10010110 10010110 10010110" 68K,IBM370: "01101001 01101001 01101001 01101001" PDP10: "(?just 36 1s?)" PDP11: "10010110 10010110" etc. Perhaps it could be optionally presented in Hex or Octal using some suitable escape ("0x9696 9696 9696 9696") if that were desired. This could be prefixed by the OS if desired "SITE UNIX 1001..." and a lot would be known. A better binary number than my example is probably needed, but the idea should be clear. The nice thing about it is the default is easy (don't do image.) The only thing that bothers me (I guess) is that the scientific community might have chosen floating point format to normalize upon. And somewhere down there a whole different project lies. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [268@spdcc.COM] <1987091716023900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dyer@spdcc.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: FTP advisory messages Message-ID: <268@spdcc.COM> Date: Thu, 17-Sep-87 20:02:39 EDT Article-I.D.: spdcc.268 Posted: Thu Sep 17 20:02:39 1987 Date-Received: Sat, 19-Sep-87 10:24:36 EDT References: <8709172107.AA16664@beno.CSS.GOV> Organization: S.P. Dyer Computer Consulting, Cambridge MA Lines: 18 In article <8709172107.AA16664@beno.CSS.GOV>, rick@SEISMO.CSS.GOV (Rick Adams) writes: > What I really want to know in this example is the packing (and > possibly byte ordering) of characters in a word. I don't believe that > all Unix implementations are 8 bits = 1 character = 1 byte. I think the > C/70 has a 9 bit byte or something. It runs Unix (I don't have my manuals > with me, but you get the idea) Puhleeaze. The C/70 has *10* bit bytes and *20* bit words, in 68K-style byte order. As you might expect, IMAGE mode was an exercise in bit manipulation. As to how it packed them together, well, that depended on what version of ftp and ftpd we had released at the time. Luckily, this confusion was never inflicted on customers, only in-house. I remember that the switch between one encoding scheme to another was only slightly less disruptive than the cutover from NCP to TCP... -- Steve Dyer dyer@harvard.harvard.edu dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,m2c}!spdcc!dyer ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12335457880.12.BILLW@MATHOM.CISCO.COM] <1987091716535500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BILLW@MATHOM.CISCO.COM (William Westfield) Newsgroups: comp.protocols.tcp-ip Subject: Re: Question about IP options Message-ID: <12335457880.12.BILLW@MATHOM.CISCO.COM> Date: Thu, 17-Sep-87 20:53:55 EDT Article-I.D.: MATHOM.12335457880.12.BILLW Posted: Thu Sep 17 20:53:55 1987 Date-Received: Sat, 19-Sep-87 18:22:11 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 36 [ Indented quotes from Jonathan Biggar, ">"ed quotes from Mike Brescia ] 2) When using either loose or strict source routing, does the next hop or the final destination go in the destination address field of the IP header? >Next hop. A rationale for this choice, based on processing power needed, is >that a gateway does not have to look at the options unless the IP destination >address is the gateway. Then you look for options, and, finding a source >route, send it back out again. Unfortunately this rationale is completely false, since there are many IP options that must be processed whether or not the IP destination is the gateway's address. (These include record route, timestamping, and security.) A better reason is the behavior that you get when some gateway does not implement source routing is much more sociable this way. Consider a packet sent from A to D with source route B:C:D, and where B does not implement source routing. If the original destination D stays in the header through the entire trip, then the packet will arrive at B, and be forwarded on to some gateway (perhaps C) without processing the source route option. C will get the packet, notice that it has an incomplete source route, and forward it to the next gateway in the list, which is still B. The packet will loop between B and C until it dies. Depending on the type of link between them, this could be very expensive in some sense. When the IP destination is replaced at each hop, all that happens is that B receives the packet, and probably throws it out due to some higher level protocol checksum faliure... Bill Westfield cisco Systems ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709172238.aa02020@Huey.UDEL.EDU] <1987091718383700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Clockwatchers beware Message-ID: <8709172238.aa02020@Huey.UDEL.EDU> Date: Thu, 17-Sep-87 22:38:37 EDT Article-I.D.: Huey.8709172238.aa02020 Posted: Thu Sep 17 22:38:37 1987 Date-Received: Sat, 19-Sep-87 16:47:57 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 Louie, Why don't you reterminate the clock on the NSF fuzzball, which would make it a functional duplicate of the NCAR machine? Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709180335.AA00659@ucbvax.Berkeley.EDU] <1987091719362300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@PARK-STREET.BBN.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Question about IP options Message-ID: <8709180335.AA00659@ucbvax.Berkeley.EDU> Date: Thu, 17-Sep-87 23:36:23 EDT Article-I.D.: ucbvax.8709180335.AA00659 Posted: Thu Sep 17 23:36:23 1987 Date-Received: Sat, 19-Sep-87 15:52:23 EDT References: <12335457880.12.BILLW@MATHOM.CISCO.COM> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 23 Bill, When I talked about processing IP options only if the packet was addressed to the gateway, that was historically accurate for the LSI11 core gateways, which did not implement record route, timestamping or security options. Because of the extra overhead of doing a complete scan of the IP options at every gateway hop, I propose, only slightly tongue-in-cheek, that we extend the IP header by 8 (16? 32?) bits for a flag word indicating that certain options are present and should be scanned. Use bit[i] to indicate the presence of an option whose value is "i". Gateways which do not handle security, for example, can rapidly dispose of (oops, forward :-) those packets with only the security option bit on. This is an extension of an earlier idea (source unknown) which used a single bit in the IP header to declare the presence of options which needed processing at every gateway. Note: if you have any flames about the specifics of the proposal, I doubt that I will answer them. I did want to get in a bid for faster handling of packets. Maybe I am still too concerned with 'efficiency'. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [13464@linus.UUCP] <1987091720120500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jed@mbunix.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Telnet/FTP for PCs with 3Com Ethernet cards, MACs, any others?? Message-ID: <13464@linus.UUCP> Date: Fri, 18-Sep-87 00:12:05 EDT Article-I.D.: linus.13464 Posted: Fri Sep 18 00:12:05 1987 Date-Received: Sat, 19-Sep-87 18:02:12 EDT Sender: news@linus.UUCP Reply-To: jed@mitre-bedford.ARPA (Daum) Distribution: world Organization: The MITRE Corporation, Bedford, Mass. Lines: 59 The following public reply to Bob Claeson is provided to spark comment. Additionally, I am interested in anyone's knowledge of any-domain implementations of Telnet (vt100, vtXXX, 3278 models 2 and 4, NVT and NVDET), FTP, and SMTP on CMC, Excelan, 3Com or you pick it. Robert Claeson (enea!pvab!robert@seismo.arpa) writes (tcp-ip message 954) RE: Telnet for a PC/3Com configuration. >> >>Which one should I use? The telnet in Sun's PC/NFS was almost useless. We >>need support for national characters, ie we need to be able to remap the >>keyboard in about the same way as SmarTerm 240. >>By the way, is it possible to use another telnet together with Sun's PC/NFS >>and 3Com's EtherLink card? And is there only plain vt100 telnets for PC's? I currently have in house three Telnet implementations: FTP Inc's "PC/TCP" FTP/Telnet software, the FTP/Telnet that is available with SUN's PC/NFS (V.2), and the Telnet/FTP from NCSA (the National Center for Supercomputing Applications). I feel the NCSA Telnet/FTP product is superior to the others in the functions it provides (and the price is right ...free). However to be fair, FTP Inc. and SUN both offer unique capabilities that may be of value to you. But that is for another discussion. NCSA's screen "capture" capability is implemented similar to the way the Kermit communications software does it. The Telnet is coupled with a vt100 emulation and others are on the way. The FTP is very easy to use but is a server-only implementation (that is, you must be logged in to the source/destination host and initiate your ftp from there; the next release may allow a user FTP). My favorite capability is multiple sessions (you can be logged in as many as 20 times and an indicator on the screen lets you know if data has been received in any of the sessions). Also, the NCSA Telnet doesn't require additional "CONFIG.SYS" drivers. As for remapping the keyboard, I use the key redefinition function of DESQview (window/task management software). I am told that Superkey and Prokey (which I will implement shortly) should also work. I have had no problems with the NCSA software working in my PC/AT with the PC/NFS drivers installed. However, I have not been able to fully test the compatibility as our NFS server is not yet installed. Also, if you have Macintoshes, you'll be glad to know there is an NCSA Telnet version for the Mac. Simtel20.arpa has a ".arc" file in PD:. Also, you can get the PC and MAC files via anonymous FTP from uxc.cso.uiuc.edu in the subdirectory NCSA. Questions or comments should be directed to one of the authors of the NCSA Telnet via mail To: "telbug%newton@uxc.cso.uiuc.edu.arpa". -=-=-=-=-=-=-=-=-=-=-=-=-=-=-> ARPA: jed@mitre-bedford.arpa > John E. Daum or jed@mitre-omaha.arpa > Phone: (402) 292-5889 > Disclaimer: My opinions are just that, and do not reflect corporate views. ------------------------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709181411.AA08835@trantor.UMD.EDU] <1987091806113000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: louie@TRANTOR.UMD.EDU (Louis A. Mamakos) Newsgroups: comp.protocols.tcp-ip Subject: Re: Clockwatchers beware Message-ID: <8709181411.AA08835@trantor.UMD.EDU> Date: Fri, 18-Sep-87 10:11:30 EDT Article-I.D.: trantor.8709181411.AA08835 Posted: Fri Sep 18 10:11:30 1987 Date-Received: Sun, 20-Sep-87 01:57:09 EDT References: <8709172238.aa02020@Huey.UDEL.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Dave, The clock and machine are feeling much better now, thank you. We would have done something like this, but the machines are in two different rooms. I decided that I would be faster to replace the disk driver than move the clock and reroute various wires, cables and other snakes. Let me know thinks don't seem back to normal. louie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [438@aoa.UUCP] <1987091808320000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mbr@aoa.UUCP (Mark Rosenthal) Newsgroups: comp.protocols.tcp-ip Subject: Anybody using CMC Transerver? (Was: Ethernet Terminal Servers?) Message-ID: <438@aoa.UUCP> Date: Fri, 18-Sep-87 12:32:00 EDT Article-I.D.: aoa.438 Posted: Fri Sep 18 12:32:00 1987 Date-Received: Sun, 20-Sep-87 03:14:43 EDT Reply-To: mbr@aoa.UUCP (Mark Rosenthal) Organization: Adaptive Optics Assoc., Cambridge, Mass. USA Lines: 12 In discussing the topic of Ethernet Terminal Servers, many people have reported on their experiences with Encore, Bridge, and Cisco. Is anybody out there using the CMC Transerver? What do you think of it? How good are its implementations of TCP/IP, telnet, rlogin? Can it drive all 10 lines at 9600 baud? 19.2 baud? What RS232 signals does it implement besides TxD, RxD, and Sig Gnd? Can individual lines be configured to pass 8-bit binary to a device (i.e. not put a special interpretation on any particular character, not discard NULL bytes)? -- Mark of the Valley of Roses ...!{harvard,ima}!bbn!aoa!mbr ...!{wjh12,mit-vax}!biomed!aoa!mbr ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709181704.AA05653@bel.isi.edu] <1987091809044900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: postel@ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: re: Source Route IP Options Message-ID: <8709181704.AA05653@bel.isi.edu> Date: Fri, 18-Sep-87 13:04:49 EDT Article-I.D.: bel.8709181704.AA05653 Posted: Fri Sep 18 13:04:49 1987 Date-Received: Sun, 20-Sep-87 03:19:01 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 1004 Network Working Group J. Postel Request for Comments: DRAFT J. Reynolds XXXX 1987 Comments on the IP Source Route Option Status of this Memo This RFC discusses a feature of the Internet Protocol (IP) used in the ARPA-Internet community, and requests discussion and suggestions for improvements of the description of this feature. Distribution of this memo is unlimited. Introduction The purpose of this memo is to expand the discussion of the IP Source Route Option and to give some examples of its use. Overview The IP Source Route option allows the originator (source host) of an IP datagram to specify a number of specific gateways the datagram must pass though in sequence before being delivered to the destination host. The Source Route Concept The concept of the Source Route Option is to let the originator (or source) of the datagram specify a list of points (gateways) the datagram is to pass through on the way to its destination. This type of explicit routing is usually not necessary since the Internet gateways exchange routing information and route datagrams based only on the destination address (and possibly other factors such as type of service). One reason for using source routing might be to reach some part of the Internet via a path that the gateways somehow don't know about via their normal routing information exchange. Another reason may be to explicitly use or avoid certain networks for performance, or administrative reasons (such as privacy, access policy, or billing). A reason for using source routing that has been exercised with good results already is testing. Source routing allows sending datagrams that transit particular Internet paths testing either particular networks or particuar gateways (or both) from a remote monitoring host. Postel & Reynolds [Page 1] RFC DRAFT XXXX 1987 The source route is implemented by including an option in the IP header that lists additional addresses. That is, a source routed datagram starts out with the address of the first stop on the route in the IP header destination address field, and the addresses of subsequent stops as elements in the option list. At each stop, an address is taken from an element of the list in the option and placed in the destination address field and that element of the list is replaced by the address of that stop. There are three IP options: Strict Source Route (SSR), Loose Source Route (LSR) and Record Route (RR). Both SSR and LSR also record the route as well. The difference between SSR and LSR is that in SSR the route must specify gateway separated by only one network, but in LSR the path between stops on the specified route maybe any length and determined by normal gateway routing. The information in a source route is a list of 32-bit IP addresses and a pointer that indicates which address in the list is to be used next. The following example shows the working of the option in simplified form. Example 1: Suppose that the source is host A, the destination is host E and the gateways to be explicitly passed through are B, C, and D. +-----+ +-----+ +-----+ +-----+ +-----+ | | | | | | | | | | | A |-----| B |-----| C |-----| D |-----| E | | | | | | | | | | | +-----+ +-----+ +-----+ +-----+ +-----+ When the datagram is sent from the source host (A) into the Internet the Source Address (SA), Destination Address (DA), Source Route List (SRL) and Source Route Pointer (SRP) the fields are: SA: A DA: B SRL: C,D,E SRP: 0 After the datagram arrives at gateway B, the gateway notices the source route option and transposes the address from the destination field and the next element of the source route list and increments the source route pointer. As the datagram leaves gateway B, the fields are: Postel & Reynolds [Page 2] RFC DRAFT XXXX 1987 SA: A DA: C SRL: B,D,E SRP: 1 At gateway C, the processing is similar. The datagram leaves gateway C with its fields appearing: SA: A DA: D SRL: B,C,E SRP: 2 At gateway D, the processing is similar. The datagram leaves gateway D with its fields appearing: SA: A DA: E SRL: B,C,D SRP: 3 Finally, the datagram arrives at host E. Even though the source route option is still present, host E knows it is the final destination because the source route pointer now indicates that the source route list is exhausted. Example 1 was simplified to present the general concept. One detail that was omitted is that each gateway really has two (or more) addresses. When the option is processed, the address that must be stored back into the option field is the address for going in the reverse direction. Example 2: Suppose that the source is host A, with address IA on net I. The destination is host E, with address LE on net L. The gateways to be explicitly passed through are B, C, and D. Each gateway has two addresses, one on each directly connected network. +-----+ +-----+ +-----+ +-----+ +-----+ | |IA IB| |JB JC| |KC KD| |LD LE| | | A |-------| B |-------| C |-------| D |-------| E | | | net I | | net J | | net K | | net L | | +-----+ +-----+ +-----+ +-----+ +-----+ When the datagram is sent from the source host (A) into the Internet, the Source Address (SA), Destination Address (DA), Source Route List (SRL), and Source Route Pointer (SRP) the fields Postel & Reynolds [Page 3] RFC DRAFT XXXX 1987 are: SA: IA DA: IB SRL: JC,KD,LE SRP: 0 After the datagram arrives at gateway B, the gateway notices the source route option and moves the address from the next element of the source route list to the destination field, places its own reverse direction address in the that element of the source route list, and increments the source route pointer. As the datagram leaves gateway B, the fields are: SA: IA DA: JC SRL: JB,KD,LE SRP: 1 At gateway C, the processing is similar. The datagram leaves gateway C with its fields appearing: SA: IA DA: KD SRL: JB,KC,LE SRP: 2 At gateway D, the processing is similar. The datagram leaves gateway D with its fields appearing: SA: IA DA: LE SRL: JB,KC,LD SRP: 3 Finally, the datagram arrives at host E. Even though the source route option is still present, host E knows it is the final destination, because the source route pointer now indicates that the source route list is exhausted. Postel & Reynolds [Page 4] RFC DRAFT XXXX 1987 An Explicit Detailed Example Recall the format of the IP header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the the source route option is shown in the extract from RFC-791 in Appendix A. Postel & Reynolds [Page 5] RFC DRAFT XXXX 1987 Example 3: Suppose that the source is host ISI-ARK, with address 128.9.0.12 on ISI-NET, the destination is host DMC-CRC, with address 128.43.0.1 on DRENET and the gateways to be explicitly passed through are ISI-WB-GW, LL-GW, and CRC-GW. Each gateway has two addresses, one on each directly connected network. +-----+ | | 128.9.0.12 |ISI |------- | ARK| /ISI-NET +-----+ / / / / +-----+ / |ISI | 28.45.0.0 -------| WB |------- 128.9.0.25 | GW| /WBNET +-----+ / / / +-----+ / | | 10.5.0.10 -------|LL-GW|------- 28.19.0.0 | | /ARPANET +-----+ / / / +-----+ / | | 128.43.1.1 -------|CRC |------- 10.1.0.15 | GW| /DRENET +-----+ / / / +-----+ / | | -------|DMC | 128.43.0.1 | CRC| +-----+ When the datagram is sent from the source host (ISI-ARK) into the Internet the Source Address (SA), Destination Address (DA), Source Route List (SRL), and Source Route Pointer (SRP) the fields are: SA: 128.9.0.12 DA: 128.9.0.25 SRL: 28.19.0.0, 10.1.0.15, 128.43.0.1 SRP: 0 Postel & Reynolds [Page 6] RFC DRAFT XXXX 1987 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128 | 9 | 0 | 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128 | 9 | 0 | 25 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 137 | 15 | 4 | 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 19 | 0 | 0 | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 0 | 15 | 128 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 43 | 0 | 1 | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ After the datagram arrives at gateway ISI-WB-GW, the gateway, notices the source route option and moves the address from the next element of the source route list to the destination field, places its own reverse direction address in the that element of the source route list, and increments the source route pointer. As the datagram leaves gateway ISI-WB-GW, the fields are: SA: 128.9.0.12 DA: 28.19.0.0 SRL: 28.45.0.0, 10.1.0.15, 128.43.0.1 SRP: 1 Postel & Reynolds [Page 7] RFC DRAFT XXXX 1987 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128 | 9 | 0 | 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 28 | 19 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 137 | 15 | 8 | 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 45 | 0 | 0 | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 0 | 15 | 128 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 43 | 0 | 1 | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Postel & Reynolds [Page 8] RFC DRAFT XXXX 1987 At gateway LL-GW, the processing is similar. The datagram leaves gateway LL-GW with its fields appearing: SA: 128.9.0.12 DA: 10.1.0.15, SRL: 28.45.0.0, 10.5.0.10, 128.43.0.1 SRP: 2 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128 | 9 | 0 | 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 10 | 1 | 0 | 15 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 137 | 15 | 12 | 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 45 | 0 | 0 | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | 0 | 10 | 128 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 43 | 0 | 1 | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ At gateway CRC-GW, the processing is similar. The datagram leaves gateway CRC-GW with its fields appearing: SA: 128.9.0.12 DA: 128.43.0.1 SRL: 28.45.0.0, 10.5.0.10, 128.43.1.1 SRP: 3 Postel & Reynolds [Page 9] RFC DRAFT XXXX 1987 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128 | 9 | 0 | 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128 | 43 | 0 | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 137 | 15 | 16 | 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 45 | 0 | 0 | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | 0 | 10 | 128 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 43 | 1 | 1 | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Finally, the datagram arrives at host DMC-CRC. Even though the source route option is still present, host DMC-CRC knows it is the final destination because the source route pointer now indicates that the source route list is exhausted. Postel & Reynolds [Page 10] RFC DRAFT XXXX 1987 Summary *****-----> [words here] References [1] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program Protocol Specification," RFC 791, USC/Information Sciences Institute, September 1981. [2] DoD Military Standard, "Internet Protocol", MIL-STD-1777, Department of Defense, August 1983. Postel & Reynolds [Page 11] RFC DRAFT XXXX 1987 Appendix A -- Extracts from RFC-791 Note: Editors notes and corrections are enclosed in angle brackets ("<", ">"), and text that should be deleted is enclosed in braces ("{","}"). Loose Source and Record Route +--------+--------+--------+---------//--------+ |10000011| length | pointer| route data | +--------+--------+--------+---------//--------+ Type=131 The loose source and record route (LSRR) option provides a means for the source of an internet datagram to supply routing information to be used by the gateways in forwarding the datagram to the destination, and to record the route information. The option begins with the option type code. The second octet is the option length which includes the option type code and the length octet, the pointer octet, and length-3 octets of route data. The third octet is the pointer into the route data indicating the octet which begins the next source address to be processed. The pointer is relative to this option, and the smallest legal value for the pointer is 4. A route data is composed of a series of internet addresses. Each internet address is 32 bits or 4 octets. If the pointer is greater than the length, the source route is empty (and the recorded route full) and the routing is to be based on the destination address field. If the address in destination address field has been reached and the pointer is not greater than the length, the next address in the source route replaces the address in the destination address field, and the recorded route address replaces the source address just used, and pointer is increased by four. The recorded route address is the internet module's own internet address as known in the environment into which this datagram is being forwarded. This procedure of replacing the source route with the recorded route (though it is in the reverse of the order, it must be in to be used as a source route) means the option (and the IP header as a whole) remains a constant length as the datagram progresses through the internet. Postel & Reynolds [Page 12] RFC DRAFT XXXX 1987 This option is a loose source route because the gateway or host IP is allowed to use any route of any number of other intermediate gateways to reach the next address in the route. Must be copied on fragmentation. Appears at most once in a datagram. Strict Source and Record Route +--------+--------+--------+---------//--------+ |10001001| length | pointer| route data | +--------+--------+--------+---------//--------+ Type=137 The strict source and record route (SSRR) option provides a means for the source of an internet datagram to supply routing information to be used by the gateways in forwarding the datagram to the destination, and to record the route information. The option begins with the option type code. The second octet is the option length which includes the option type code and the length octet, the pointer octet, and length-3 octets of route dAata. The third octet is the pointer into the route data indicating the octet which begins the next source address to be processed. The pointer is relative to this option, and the smallest legal value for the pointer is 4. A route data is composed of a series of internet addresses. Each internet address is 32 bits or 4 octets. If the pointer is greater than the length, the source route is empty (and the recorded route full) and the routing is to be based on the destination address field. If the address in the destination address field has been reached and the pointer is not greater than the length, the next address in the source route replaces the address in the destination address field, and the recorded route address replaces the source address just used, and pointer is increased by four. The recorded route address is the internet module's own internet address as known in the environment into which this datagram is being forwarded. This procedure of replacing the source route with the recorded route (though it is in the reverse of the order, it must be in to be used as a source route) means the option (and the IP header as a whole) remains a constant length as the datagram progresses through the internet. Postel & Reynolds [Page 13] RFC DRAFT XXXX 1987 This option is a strict source route because the gateway or host IP must send the datagram directly to the next address in the source route through only the directly connected network indicated in the next address to reach the next gateway or host specified in the route. Must be copied on fragmentation. Appears at most once in a datagram. Record Route +--------+--------+--------+---------//--------+ |00000111| length | pointer| route data | +--------+--------+--------+---------//--------+ Type=7 The record route option provides a means to record the route of an internet datagram. The option begins with the option type code. The second octet is the option length which includes the option type code and the length octet, the pointer octet, and length-3 octets of route data. The third octet is the pointer into the route data indicating the octet which begins the next area to store a route address. The pointer is relative to this option, and the smallest legal value for the pointer is 4. A recorded route is composed of a series of internet addresses. Each internet address is 32 bits or 4 octets. If the pointer is greater than the length, the recorded route data area is full. The originating host must compose this option with a large enough route data area to hold all the address expected. The size of the option does not change due to adding addresses. The intitial contents of the route data area must be zero. When an internet module routes a datagram it checks to see if the record route option is present. If it is, it inserts its own internet address as known in the environment into which this datagram is being forwarded into the recorded route beginning at the octet indicated by the pointer, and increments the pointer by four. If the route data area is already full (the pointer exceeds the length) the datagram is forwarded without inserting the address into the recorded route. If there is some room but not enough room for a full address to be inserted, the original datagram is considered to be in error and is discarded. In either case, an ICMP parameter problem message may be sent to the source host [3]. Postel & Reynolds [Page 14] RFC DRAFT XXXX 1987 Not copied on fragmentation, goes in first fragment only. Appears at most once in a datagram. Postel & Reynolds [Page 15] RFC DRAFT XXXX 1987 Appendix B -- Extracts from MIL-STD-1777 Note: Editors notes and corrections are enclosed in angle brackets ("<", ">"), and text that should be deleted is enclosed in braces ("{","}"). 9.2.1.2 Routing options. IP provides a mechanism, called source routing, to supplement the gateway's independent routing decisions. This mechanism allows an upper layer protocol to influence the gateway route in which a datagram traverses. The UPL can pass a list of internet addresses, called a source route list, as one of the SEND service request parameters. Each address in the list, except for the last, is an intermediate gateway destination. The last address on the list is the final destination. The source IP module uses its normal routing mechanism to transmit the datagram to the first address in the source route list. Then the gateway IP replaces source route list entry with its own address as known in the environment into which it is forwarding the datagram. Thus, the datagram follows the source route while recording its "inverse" or recorded route. 9.2.1.2.1 Routing types. Two kinds of source routing are proviced by IP: loose and strict. With loose source routing, the host and gateway IP modules along the route may use any number of other intermediate gateways to reach the addresses in the source list. With strict source routing, the datagram must travel directly (i.e., through only the directly connected subnetwork indicated by each address) to each address on the source list. When the source route cannot be followed, the source host IP is notified with an error message. For testing or diagnostic purposes, a ULP can acquire a datagram's record route (independent of the source route option) by using the record route mechanism. The sending ULP supplies an empty record route list and indicates that the gateway route is to be recorded in transit. Then, as each gateway IP module on the gateway route relays the datagram, it adds its address as known in the succeeding environment to the record route list. The destination ULP receives the original datagram along with the record route list which, if reversed, provides a source route to the sending ULP. If more gateways are traversed than can be recorded in the list, the additional gateway addresses are not recorded. Problems with the record route option discovered in transit are reported to the source host IP. When using a routing otion, the source ULP must provide a large enough route list to accommodate all the routing information expected. The size of a routing option does Postel & Reynolds [Page 16] RFC DRAFT XXXX 1987 not change due to adding addresses. 9.3.15.4 Loose source and record route. option type: 131 option length: variable The loose source route option provides a way for the source ULP of a datagram to supply routing information to be used by IP modules along the gateway route. At the same time, the "inverse" route is recorded in the option field. This option {is not} copied on fragmentation. It appears at most once in a datagram. The option begins with the option type code. The second octet is the option length which includes the option type octet, the length octet, the pointer octet, and the source route list. The third octet is a pointer into the route data indicating the octet which begins the next source address to be processed. The pointer is relative to this option, and its smallest legal value is 4. A loose source route list is composed of one or more internet addresses identifying intermediate gateways to be visited in transit. Each internet address is 4 octets long. When a gateway in the source route list is visited, the gateway address (as known in the environment into which the datagram is being forwarded) replaces that list entry . The size of this option is fixed by the source. It cannot change to accommodate additional information. The routing options are described in section {9.2.1.1} <9.2.1.2>. 9.3.15.5 Strict source and record route. option type: 137 option length: variable The strict source route option provides a way for the source ULP of a datagram to name the exact set of IP modules to be visited along the gateway route. At the same time, the "inverse" route is recorded in the option field. This option must be copied on fragmentation. It appears at most once in a datagram. The option begins with the option type code. The second octet is the option length which includes the option type octet, the length octet, the pointer octet, and the source route list. The third octet is a pointer into the route data indicating the octet which begins the next source address to be processed. The pointer is relative to this option, and its smallest legal value is 4. A strict source route list is composed of one or more internet addresses identifying the gateways to be visited in transit. The datagram must visit exactly the gateways listed, traversing only the directly connected subnetworks indicated in the route list addresses. When a gateway in the source route list is visited, the gateway address (as known in the environment into which the Postel & Reynolds [Page 17] RFC DRAFT XXXX 1987 datagram is being forwarded) replaces that list entry . The size of this option is fixed by the source. It cannot change to accommodate additional information. Routing options are described in section {9.2.1.1} <9.2.1.2>. 9.3.15.6 Record route. option type: 7 option length: variable The record route option provides a way to record a datagram's gateway route. This option is not copied on fragmentation. It appears at most once in a datagram. The option begins with the option type code. The second octet is the option length which includes the option type code, the length octet, and the return route list. The third octet is a pointer into the route data indicating the octet which begins the next area to store a route address. The pointer is relative to this option, and the smallest legal value for the pointer is 4. A record route list is composed of a series of internet addresses. Each internet address is 4 octets long. The source ULP provides a route list with zero value entries. As each gateway is visited in transit, it registers its address in the next free entry (indicated by the pointer). When the pointer is greater than the length, the record route list is full. No additional addresses are recorded, even if more are visited before arriving at the destination. The size of this option is fixed by the source. It cannot cnange to accommodate additional information. The routing options are described in section {9.2.1.1} <9.2.1.2>. 9.4.6.3.13 Route. Editors' Notes Postel & Reynolds [Page 18] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987091811220000> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Fri 18 Sep 87 14:24:34-PDT Received: from UCIVMSA.BITNET by wiscvm.wisc.edu ; Fri, 18 Sep 87 16:23:52 CDT Date: 18 SEP 87 14:22-SYS From: mslagley%UCIVMSA.BITNET@wiscvm.wisc.edu To: TCP-IP@SRI-NIC.ARPA Subject: List of TCP/IP software for various hosts X-Original_To: TCP-IP%SRI-NIC.ARPA@orion X-Routing: SMTPUSER @ WISCVM Received: from ORION by UCICP6 with PMDFm; 18 Sep 1987 14:13:21 Received: from localhost by orion.cf.uci.edu id a026076; 18 Sep 87 13:42 PDT From: Mike Slagley Date: Fri, 18 Sep 87 13:42:25 -0700 Sender: mslagley@orion.cf.uci.edu We at University of California at Irvine we are constructing a list of recommended TCP/IP software for users. Those hosts not using Berkeley UNIX are the ones which need added software. Some of the most popular types are: IBMPC + compatibles running DOS. There are PC networks with Novell, 3COMM, PC-NFS software. Apple Macintosh, with Appletalk networks. Vaxes + MicroVaxes running VMS. PC's running OS/2 and UNIX System V will probably be popular. If anybody else has a list already compiled of TCP/IP software available for one or more hosts, we would appreciate getting a copy. Information on individual programs would also be appreciated. If software is commercial it would also be nice to know an approximate price. Any comments about successful or unsuccessful use of software or hardware would be helpful. The list will be made available to others on request. Thanks for any help: Bitnet = MWSlagley%UCI Mike Slagley Network and Telecommunications University of CA, Irvine, 92617 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709181935.AA24184@faline.bellcore.com] <1987091811351300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@FALINE.BELLCORE.COM (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: Re: Question about IP options Message-ID: <8709181935.AA24184@faline.bellcore.com> Date: Fri, 18-Sep-87 15:35:13 EDT Article-I.D.: faline.8709181935.AA24184 Posted: Fri Sep 18 15:35:13 1987 Date-Received: Sun, 20-Sep-87 04:38:04 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Just how many datagrams in the Internet even carry options anyway? I recently discovered that the implementation of source routing I did over a year ago was buggy. Not because it didn't work in operation, but because I re-read the spec the other night and realized I had done it wrong. I've never even seen a datagram with options. It might seem that it's not really worth worrying much about performance when processing IP options if they are that rare. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709182139.AA19000@ucbvax.Berkeley.EDU] <1987091813554400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mslagley@UCIVMSA.BITNET Newsgroups: comp.protocols.tcp-ip Subject: List of TCP/IP software for various hosts Message-ID: <8709182139.AA19000@ucbvax.Berkeley.EDU> Date: Fri, 18-Sep-87 17:55:44 EDT Article-I.D.: ucbvax.8709182139.AA19000 Posted: Fri Sep 18 17:55:44 1987 Date-Received: Sun, 20-Sep-87 04:52:46 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 32 Received: from ORION by UCICP6 with PMDFm; 18 Sep 1987 14:13:21 Received: from localhost by orion.cf.uci.edu id a026076; 18 Sep 87 13:42 PDT From: Mike Slagley Date: Fri, 18 Sep 87 13:42:25 -0700 Sender: mslagley@orion.cf.uci.edu We at University of California at Irvine we are constructing a list of recommended TCP/IP software for users. Those hosts not using Berkeley UNIX are the ones which need added software. Some of the most popular types are: IBMPC + compatibles running DOS. There are PC networks with Novell, 3COMM, PC-NFS software. Apple Macintosh, with Appletalk networks. Vaxes + MicroVaxes running VMS. PC's running OS/2 and UNIX System V will probably be popular. If anybody else has a list already compiled of TCP/IP software available for one or more hosts, we would appreciate getting a copy. Information on individual programs would also be appreciated. If software is commercial it would also be nice to know an approximate price. Any comments about successful or unsuccessful use of software or hardware would be helpful. The list will be made available to others on request. Thanks for any help: Bitnet = MWSlagley%UCI Mike Slagley Network and Telecommunications University of CA, Irvine, 92617 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [654@varian.UUCP] <1987091814171200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: david@varian.UUCP (David Brown) Newsgroups: comp.protocols.tcp-ip Subject: CMU-TEK + DECnet? Message-ID: <654@varian.UUCP> Date: Fri, 18-Sep-87 18:17:12 EDT Article-I.D.: varian.654 Posted: Fri Sep 18 18:17:12 1987 Date-Received: Sun, 20-Sep-87 15:25:55 EDT Organization: Varian, Walnut Creek CA Lines: 10 Can anyone tell me what ethernet boards are supported in CMU-TEK TCP/IP? We're interested in using DEC boards (DEUNA, DELUA, DEQNA). Can CMU-TEK be run simlutaneously with DECnet? Thanks in advance -- David Brown (415) 945-2199 Varian Instruments 2700 Mitchell Dr. Walnut Creek, Ca. 94598 {ptsfa,lll-crg,zehntel,dual,amd,fortune,ista,rtech,csi,normac}!varian!david ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709190011.aa10636@Huey.UDEL.EDU] <1987091820112500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Clockwatchers beware Message-ID: <8709190011.aa10636@Huey.UDEL.EDU> Date: Sat, 19-Sep-87 00:11:25 EDT Article-I.D.: Huey.8709190011.aa10636 Posted: Sat Sep 19 00:11:25 1987 Date-Received: Wed, 23-Sep-87 01:02:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Louie, Things do seem better, although last night (before you redrived?) I noticed a few timewarps between umd1 and udel1. Note that the Linkabit clock has frozen again. They won't fix it, since that costs money, so Woody is reduced to conking it with a wrench, which sometimes even wakes it up. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1419@geac.UUCP] <1987092004264200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: david@geac.UUCP (David Haynes) Newsgroups: comp.protocols.tcp-ip Subject: Re: Benchmarks for high-level protocols Message-ID: <1419@geac.UUCP> Date: Sun, 20-Sep-87 08:26:42 EDT Article-I.D.: geac.1419 Posted: Sun Sep 20 08:26:42 1987 Date-Received: Sun, 20-Sep-87 18:35:38 EDT References: <1514@sics.se> Reply-To: david@geac.UUCP (David Haynes) Organization: The little blue rock next to that twinkly star. Lines: 67 In article <1514@sics.se> erikn@sics.se (Erik Nordmark) writes: >Sender: >Reply-To: erikn@sics.se (Erik Nordmark) >Followup-To: >Distribution: world >Organization: Swedish Institute of Computer Science, Kista >Keywords: benchmark performance > >To my knowledge the standard way of comparing protocol performance >is to transfer a large file between two machines using the different >protocols. > >My question to the net is if anybody uses more sophisticated benchmarks >that take into account e.g. real-time communication, transaction-style >communication, the overhead for multiple connections, the protocol's >ability to handle packet loss due to the sender(s) overrunning the >receiver et.c. et.c. >(Pointers to any litterature on the topic are appreciated too!) > >If the response to this message is significant I'll summarize to the net! > >------------------------------------------------------------------------- >Erik Nordmark I have been using a home-brew version of the "ping" program to test the relative performance of STREAM and DATAGRAM messages in the UNIX and INTERNET domains of BSD unix. Primarily, the code asks for a packet size and the number of messages to be sent and then sets up a bounce-back type connection between the server and the client. Time is taken to complete all the messages and the throughput in messages per second and bytes per second are taken. Modifications I want to make (if I ever get the time :-)) are to allow for different sized packets (random and double-bell curve distribution) and to have the packet carry some of the timing information. As a second test, I have almost completed the internet version of Stonebreakers' concurrency control model for (relational) databases. The UNIX domain version works just fine. The idea is to have a client process which simulates a "user" or a number of users entering transactions of various size and length. The actual properties of these users can be configured by the tester. The system then moves the transactions through the concurrency controller model and performs such things as re-tries, transaction commits, transaction aborts, etc. until all transactions are completed. (Actually, the model runs forever as it sits now, we just watch it run for the first 1,000 transactions or so and see how it doing.) The entire system is controlled via a master clock which simulates the system clock in a machine. The whole system requires the co-operation of 19 distict processes. This, I think, makes a nice benchmark set for any message-based communications system. -david- -- David Haynes [ mnetor, yetti, utgpu] ! geac ! david Geac Computers International Inc. Wise words in mouths of fools 350 Steelcase Road,Markham, Ontario, do oft themselves belie. CANADA, L3R 1B3 +1 416 475 0525 x 3420 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [763@mapper.UUCP] <1987092010001100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ksand@mapper.UUCP (Kent Sandvik++) Newsgroups: comp.protocols.tcp-ip Subject: Re: Unisys 5000, Unix, and TCP/IP Message-ID: <763@mapper.UUCP> Date: Sun, 20-Sep-87 14:00:11 EDT Article-I.D.: mapper.763 Posted: Sun Sep 20 14:00:11 1987 Date-Received: Sun, 27-Sep-87 09:36:09 EDT References: <8709041300.AA05135@ucbvax.Berkeley.EDU> Reply-To: ksand@mapper.UUCP (Kent Sandvik++) Organization: UNISYS UNIX Support, Stockholm, SWEDEN Lines: 28 In article <8709041300.AA05135@ucbvax.Berkeley.EDU> AFDDN.TCP-IP@GUNTER-ADAM.ARPA writes: > > Just a request for any information out there. Does anybody have any >experience with internetting Unisys 5000s? These beasts run some flavor >of Unix. The words filtering through the grapevine are that Unisys >wrote TCP/IP, FTP, SMTP and Telnet from scratch, and that there are a few >problems with it. Any comments are welcome. >Darrel Beach >------- Yeah, we beasts run an ugly UNIX flavour called SysV, yacky :-). Also the internetworking comes from Excelan as an OEM product, and those guys wrote TCP/IP also for VMS and Sun machines. I think there are a few problems, but there are always problems with all software in general. I've tested the r-series commands (rsh, rcp, rlogin) to a VAX running 4.2 BSD, and also the ftp and telnet to SUN:s and Apollo workstations. We found *one* bug in connection with a Bridge Server and telnet (a minor one), and this was corrected in the latest release. Don't trust the grapevine, man... -Kent Sandvik- -- |COMPRESSED SIGNATURE:ADDRESS:Vallgatan7,17191SolnaSwedenPHONE:+46 8-551639| |job,-7333235 homeARPA:enea!mapper!ksand@seismo.arpa UUCP:ksand@mapper.UUCP| |Thrue Utopia Fan\007.Telex-to-work:10499.Looking-for-other-ROLAND-D-50-own| |ers.DOB:600418.Discl:They just don't know(Oliver North).FIAWOL.Oh, shitEOT| ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709212032.AA05963@devvax.TN.CORNELL.EDU] <1987092112592700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: fedor@DEVVAX.TN.CORNELL.EDU (Mark Fedor) Newsgroups: comp.protocols.tcp-ip Subject: RIP congestion woes...... Message-ID: <8709212032.AA05963@devvax.TN.CORNELL.EDU> Date: Mon, 21-Sep-87 16:59:27 EDT Article-I.D.: devvax.8709212032.AA05963 Posted: Mon Sep 21 16:59:27 1987 Date-Received: Wed, 23-Sep-87 01:01:08 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 39 Hi people. Recently here at cornell we have been experiencing a number of strange routing problems. Routes on certain vaxen gateways were being mysteriously timed out, while other dedicated gateway boxes seemed fine. Here at Cornell, we use RIP and everything is dynamic. We have Proteon P4200's and vaxen running gated/routed for gateways. Our ARPAnet gateway, CU-ARPA was one of the victims of this problem. CU-ARPA is a vax750 with 2 DEUNA's and one Pronet-10 interface. CU-ARPA also has an ARPAnet interface. After pulling my hair out and checking the routing software, I noticed that our vax was experiencing RIP congestion and couldn't keep up with all the RIPpers on its networks. On its Pronet 10 interface we have approx 11 RIPpers. On 1 of its Ethernet interfaces we have approx 7 RIPpers. on the other Ethernet interface we have 2 RIPpers. Plus, since we have a large number of networks being RIPped around, each gateway sends out 3 RIP packets for a complete update. The routing process opens one socket and listens on the RIP port. If I read the UDP code right, each socket allocates space for 4k of datagrams. CU-ARPA is easily dropping RIP packets left and right. Has anyone else experienced this? Any suggestions? I suppose I could increase "udp_recvspace" in netinet/udp_usrreq.c, but that would only prolong the agony. I know, I know, get a real machine for a gateway..... :^) Thanks. Mark P.S. Not suprisingly, the Proteon P4200 is having no problems. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [15972@hi.UUCP] <1987092114125600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kurt@hi.UUCP (Kurt Zeilenga) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans Subject: DSU/CSU units Message-ID: <15972@hi.UUCP> Date: Mon, 21-Sep-87 18:12:56 EDT Article-I.D.: hi.15972 Posted: Mon Sep 21 18:12:56 1987 Date-Received: Wed, 23-Sep-87 01:44:48 EDT Organization: U. of New Mexico, Albuquerque Lines: 2 Well, now I need info on good DSU/CSU units for T1. Any information on good vendors would be greatly appreciated. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092115172500> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Mon 21 Sep 87 12:22:39-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA12622; Mon, 21 Sep 87 11:54:10 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: 21 Sep 87 15:17:25 GMT From: rti!xyzzy!meissner@mcnc.org (Michael Meissner) Organization: Data General (Languages @ Research Triangle Park, NC.) Subject: Re: HELP: select() under sockets Message-Id: <267@xyzzy.UUCP> References: <8709091653.AA15944@topaz.rutgers.edu> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa In article <8709091653.AA15944@topaz.rutgers.edu> ron@topaz.rutgers.EDU (Ron Natalie) writes: > The other arguments to select are pointers to bit fields so assumably > > char buf[10]; > > select(80, buf, (char *) 0, (char *) 0, (char *) 0, (time_t) 0) > In 4.2 systems the three pointer arguments are pointers to INT's, not char's. In 4.3 this was changed to be the type fd_set (declared in sys/types.h), which is a structure big enough to hold 256 file descriptors, with a way to expand it further. In no case is a character array used. This may be seen as picking nits, but it becomes important on machines that have different representations for pointers to char's and other pointers. -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner Arpa/Csnet: meissner@dg-rtp.DG.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709220136.AA16822@renoir.Berkeley.EDU] <1987092117362900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sklower@RENOIR.BERKELEY.EDU (Keith Sklower) Newsgroups: comp.protocols.tcp-ip Subject: Re: RIP congestion woes...... Message-ID: <8709220136.AA16822@renoir.Berkeley.EDU> Date: Mon, 21-Sep-87 21:36:29 EDT Article-I.D.: renoir.8709220136.AA16822 Posted: Mon Sep 21 21:36:29 1987 Date-Received: Wed, 23-Sep-87 05:03:17 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 36 In his message of Mon, 21 Sep 87 16:32:08 -0400, Mark Fedor writes: : The routing process opens one socket and listens on the : RIP port. If I read the UDP code right, each socket : allocates space for 4k of datagrams. CU-ARPA is : easily dropping RIP packets left and right. : : Has anyone else experienced this? Any suggestions? I suppose : I could increase "udp_recvspace" in netinet/udp_usrreq.c, : but that would only prolong the agony. In fact, this has been noticed here at Berkeley as well. It is possible in 4.3 unix to increase the buffering for a particular datagram socket, and the current version of routed has been changed to do that to circumvent this problem. (There have been other changes since 4.3, but Mike Karels is traveling, and will not be able to supply a definitive statement about which are worth incorporating until his return). In the meantime, you can apply this patch to routed/main.c: *** main.c.fix Mon Sep 21 18:22:13 1987 --- main.c Mon Sep 21 18:19:11 1987 *************** *** 186,195 **** close(s); return (-1); } - on = 48*1024; - if (setsockopt(s, SOL_SOCKET, SO_RCVBUF, &on, sizeof (on)) < 0) - syslog(LOG_ERR, "setsockopt SO_RCVBUF: %m"); - if (bind(s, sin, sizeof (*sin), 0) < 0) { perror("bind"); syslog(LOG_ERR, "bind: %m"); --- 186,191 ---- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092205191900> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Tue 22 Sep 87 08:33:06-PDT Received: from TCSVM.TULANE.EDU by wiscvm.wisc.edu ; Tue, 22 Sep 87 10:32:28 CDT Received: by TCSVM (Mailer X1.25) id 0395; Tue, 22 Sep 87 10:25:20 CDT Date: Tue, 22 Sep 87 10:19:19 CDT From: Bryan McWilliams Subject: Re: DSU/CSU units To: TCP-IP@SRI-NIC.ARPA In-Reply-To: Message of 21 Sep 87 22:12:56 GMT from Kurt, In response to request for CSU/DSU Go with Verilink. you can order them through DCA direct at 404-442-4244. They're 2395.00 each, but if you can get the educational discount you'll save another 30%. Bryan McWilliams Manager, Network Services Tulane University OPRBBDM@TCSVM 504-865-5631 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709221322.AA16673@jvnca.csc.org] <1987092205221500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: heker@JVNCA.CSC.ORG (Sergio Heker) Newsgroups: comp.protocols.tcp-ip Subject: Re: DSU/CSU units Message-ID: <8709221322.AA16673@jvnca.csc.org> Date: Tue, 22-Sep-87 09:22:15 EDT Article-I.D.: jvnca.8709221322.AA16673 Posted: Tue Sep 22 09:22:15 1987 Date-Received: Thu, 24-Sep-87 04:33:54 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Kurt, We have been using the AVANTI Tpac DSU/CSU multiplexer for over a year with good results. If you need more info contact me directly. -- 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---- [8709221539.AA06394@ucbvax.Berkeley.EDU] <1987092207191900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: OPRBBDM@TCSVM.BITNET (Bryan McWilliams) Newsgroups: comp.protocols.tcp-ip Subject: Re: DSU/CSU units Message-ID: <8709221539.AA06394@ucbvax.Berkeley.EDU> Date: Tue, 22-Sep-87 11:19:19 EDT Article-I.D.: ucbvax.8709221539.AA06394 Posted: Tue Sep 22 11:19:19 1987 Date-Received: Thu, 24-Sep-87 05:18:36 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Kurt, In response to request for CSU/DSU Go with Verilink. you can order them through DCA direct at 404-442-4244. They're 2395.00 each, but if you can get the educational discount you'll save another 30%. Bryan McWilliams Manager, Network Services Tulane University OPRBBDM@TCSVM 504-865-5631 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092207330000> Received: from bluto.scc.com by SRI-NIC.ARPA with TCP; Tue 22 Sep 87 09:57:40-PDT Date: 22 Sep 87 12:33:00 EST From: "GBURG::ENGER" Subject: DSU/CSU units To: "tcp-ip" cc: enger Reply-To: "GBURG::ENGER" We have a couple of T1 circuits, but the equipment on the ends functions as its own "DSU", so all that is required are outboard CSU units. We use Digital Link Corp. Model 551C. I think we have had three blow out so far. And a fourth leaked span power to its chasis! It turns out they had problems with the physical construction of the units. A bolt came very close to the circuit board and often shorted or arcked during electrical storms, etc. The factory supposedly installed an engineering modification (cutting the excess off of the bolts probably) to lower the likelyhood of lightning damage. When one of the units came back from getting "the fix", its Percent Error Free Seconds display simply counted down constantly. The Error Free seconds display is a nice feature. It keeps an "objective" eye on the status of the line. Makes it real easy to point the finger at the phone company. Other than span power outages due to lightning blowing the CO fuses, the only problem I have ever had with the T1s was a bad punch at the undergroud, and the CSU EFS display showed it as an excessive error rate, and indicated which direction the problem was in. The local operating company fixed it promptly, no questions asked. They took one look at the display on the csu, and went to work on the span. If you wish to contact them, Digital Link is in Sunnyvale, Ca Phone number 408-745-6200 Good luck, bob From: GBURG::ENGER "Robert M. Enger {CONTEL Fed. Sys} (301)840-4906" 22-SEP-1987 12:42 To: GBURG::MAILER,ENGER Subj: RE: [TCP/IP Mail From: ] ludwig non-functional when net is down I don't "think" the ypbind has anything to do with the iebark reset. I'll check into it. bob (I think rebooting the machine is what cleared your problem??) bob ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709221709.AA08289@ucbvax.Berkeley.EDU] <1987092209330000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: enger%gburg.DECnet@BLUTO.SCC.COM ("GBURG::ENGER") Newsgroups: comp.protocols.tcp-ip Subject: DSU/CSU units Message-ID: <8709221709.AA08289@ucbvax.Berkeley.EDU> Date: Tue, 22-Sep-87 13:33:00 EDT Article-I.D.: ucbvax.8709221709.AA08289 Posted: Tue Sep 22 13:33:00 1987 Date-Received: Thu, 24-Sep-87 05:38:09 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "GBURG::ENGER" Organization: The ARPA Internet Lines: 39 We have a couple of T1 circuits, but the equipment on the ends functions as its own "DSU", so all that is required are outboard CSU units. We use Digital Link Corp. Model 551C. I think we have had three blow out so far. And a fourth leaked span power to its chasis! It turns out they had problems with the physical construction of the units. A bolt came very close to the circuit board and often shorted or arcked during electrical storms, etc. The factory supposedly installed an engineering modification (cutting the excess off of the bolts probably) to lower the likelyhood of lightning damage. When one of the units came back from getting "the fix", its Percent Error Free Seconds display simply counted down constantly. The Error Free seconds display is a nice feature. It keeps an "objective" eye on the status of the line. Makes it real easy to point the finger at the phone company. Other than span power outages due to lightning blowing the CO fuses, the only problem I have ever had with the T1s was a bad punch at the undergroud, and the CSU EFS display showed it as an excessive error rate, and indicated which direction the problem was in. The local operating company fixed it promptly, no questions asked. They took one look at the display on the csu, and went to work on the span. If you wish to contact them, Digital Link is in Sunnyvale, Ca Phone number 408-745-6200 Good luck, bob From: GBURG::ENGER "Robert M. Enger {CONTEL Fed. Sys} (301)840-4906" 22-SEP-1987 12:42 To: GBURG::MAILER,ENGER Subj: RE: [TCP/IP Mail From: ] ludwig non-functional when net is down I don't "think" the ypbind has anything to do with the iebark reset. I'll check into it. bob (I think rebooting the machine is what cleared your problem??) bob ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [559330885.25037@bucasb.bu.edu] <1987092209412500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mike@bucasb.bu.edu (Michael Cohen) Newsgroups: comp.protocols.tcp-ip,comp.os.vms,comp.unix.wizards,comp.unix.questions Subject: Secure Telnet/FTP Message-ID: <559330885.25037@bucasb.bu.edu> Date: Tue, 22-Sep-87 13:41:25 EDT Article-I.D.: bucasb.559330885.25037 Posted: Tue Sep 22 13:41:25 1987 Date-Received: Thu, 24-Sep-87 05:34:51 EDT Sender: mike@bucasb.bu.edu Reply-To: mike@bucasb.UUCP (Michael Cohen) Organization: Boston U., Center for Adaptive Systems Lines: 5 Keywords: tcp-ip telnet ftp security Is there a version of telnet/ftp running under VMS which runs in such a way so that access can be restricted to certain users. This is a query for someone running telnet/ftp a secure site, and is unable to run it in standard configuration at his site because password security is not enough. Thanks much for your response ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709222207.AA03045@venera.isi.edu] <1987092214072900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: pvm@VENERA.ISI.EDU (Paul Mockapetris) Newsgroups: comp.protocols.tcp-ip Subject: Change in root servers Message-ID: <8709222207.AA03045@venera.isi.edu> Date: Tue, 22-Sep-87 18:07:29 EDT Article-I.D.: venera.8709222207.AA03045 Posted: Tue Sep 22 18:07:29 1987 Date-Received: Thu, 24-Sep-87 07:25:25 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 The root server set for the domain system will change in October. The C.ISI.EDU machine is going to its just reward, and its name server will stop some time in October. Toast its demise with a root bier. The NIC will remove it from the domain database approximately one week in advance. Gunter-Adam.arpa will join the official set of root servers before C's demise. As a more long term solution, shakedown of several new root servers "closer" to the east coast, NSFnet, etc is underway, and should be provide a long term solution. paul ----MESSAGE-END---- ----MESSAGE-BEGIN---- [876@saturn.ucsc.edu] <1987092217464300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: eshop@saturn.ucsc.edu (Jim Warner) Newsgroups: comp.protocols.tcp-ip Subject: Re: DSU/CSU units Message-ID: <876@saturn.ucsc.edu> Date: Tue, 22-Sep-87 21:46:43 EDT Article-I.D.: saturn.876 Posted: Tue Sep 22 21:46:43 1987 Date-Received: Fri, 25-Sep-87 07:25:26 EDT References: <8709221539.AA06394@ucbvax.Berkeley.EDU> Reply-To: eshop@saturn.ucsc.edu (Jim Warner 408-429-2606) Organization: University of California, Santa Cruz; CIS/CE Lines: 31 In article <8709221539.AA06394@ucbvax.Berkeley.EDU> OPRBBDM@TCSVM.BITNET (Bryan McWilliams) writes: >Kurt, In response to request for CSU/DSU Go with Verilink. you can >order them through DCA direct at 404-442-4244. They're 2395.00 each, but >if you can get the educational discount you'll save another 30%. > I wish I could be so positive about Verilink. It looks like they are nothing but trouble from my perspective. Ours get into funny states which they can't recover from without pulling the plug. I mean that literally. They have no on/off switch or reset button. The factory recommendation to unjam one of these things is to pop the modules out with the power on. That grates. There's not even a button to force it out of loopback mode (again - just pull the plug). I wish I could be more specific about what "funny states" means. What we think happens is that something happens to a phone circuit that causes a lot of errors. After several hours of whatever mistreatment the phone co has to offer, the Verilink finally gets confused, looses sync and locks up. After the phone line has gotten good again, the Verilink doesn't recover by itself. Besides that, they break a lot. We're working on our third unit this year. Another thing that's been a headache is their 8ZBS encoding. While the encoding itself isn't a problem, the equipment that our telco gives its people sees a circuit that is working perfectly as having thousands of errors per second. In fairness to Verilink, this last point is mostly a telco problem, but the bottom line is that our phone co can't passively monitor our line to tell us what it looks like from their perspective. That hurts. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092303250000> Received: from twg.arpa by SRI-NIC.ARPA with TCP; Wed 23 Sep 87 10:30:24-PDT Date: 23 Sep 87 10:25:00 PDT From: "Jerry Scott" Subject: Put me on the list To: "tcp-ip" Reply-To: "Jerry Scott" Sorry to bother the net with this but requests to tcp-ip-request seem to not be heard. Please add address to this distribution list. Thanks, Jerry Scott ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [ID8411.D870923.T094140.BDK@UNB] <1987092304414000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BDK@UNB.BITNET Newsgroups: comp.protocols.tcp-ip Subject: PCP/IP Message-ID: Date: Wed, 23-Sep-87 08:41:40 EDT Article-I.D.: UNB.ID8411.D870923.T094140.BDK Posted: Wed Sep 23 08:41:40 1987 Date-Received: Sat, 26-Sep-87 01:49:10 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 2 As a potential new user of TCP and IP I would like to get some info on PCP/IP. What is it and where can I get a copy? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092305555100> Received: from GUNTER-ADAM.ARPA by SRI-NIC.ARPA with TCP; Wed 23 Sep 87 08:56:56-PDT Date: 23 Sep 1987 10:55:51 CDT Subject: Can of worms revisited From: AFDDN.TCP-IP@GUNTER-ADAM.ARPA To: tcp-ip@SRI-NIC.ARPA cc: AFDDN.TCP-IP@GUNTER-ADAM.ARPA To anyone who might know, especially Andy or Sharon, I've been trying to get someone(mostly DCA) to specify to me exactly what a "packet" is in terms of the billing algorithm. Since the billing algorithm is based on the traffic stats gathered by the PSN's, I'm really asking what are the packets reflected on the throughput reports. I make the differentiation between X.25 packets which can be anywhere from 128 to 1024 bytes, and the subnet "packets" passed between E-to-E in the PSNs. If memory serves me, the EE's break "messages" into 128 byte subnet "packets" for sending thru the backbone. X.25 packets, (basic that is) are viewed as messages, therefore a 1024 byte X.25 packet is 8 subnet "packets". With standard X.25, your message is a complete packet sequence and is actually now the length of you IP datagrams. But the the datagram is still broken into 128 byte "packets" by EE. If all this is true then a you could calculate the minimum number of "packets" to send x number of bytes thru the network. Not really that easy, but a place to start. Darrel Beach AF DDN PMO ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092306063400> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Wed 23 Sep 87 09:19:27-PDT Received: from TCSVM.TULANE.EDU by wiscvm.wisc.edu ; Wed, 23 Sep 87 11:18:51 CDT Received: by TCSVM (Mailer X1.25) id 4015; Wed, 23 Sep 87 11:13:40 CDT Date: Wed, 23 Sep 87 11:06:34 CDT From: Bryan McWilliams Subject: Re: DSU/CSU units To: TCP-IP@SRI-NIC.ARPA In-Reply-To: Message of 23 Sep 87 01:46:43 GMT from I'm sorry to hear about your Verilink problems. Were I suffering the same difficulty I surely would not have recommended the box. One question, are you span powered? South Central Bell (in Louisiana) provides T-1 via fiber only, so my boxes are powered by standalone 48 v. power supplies from Tellabs. You may be taking some hits on the span if that's where your D.C is coming from. We test our line with firebird sets, and they show zero errors. The gear the phone company uses is not nearly as sophisticated (at laest in our region). I've had 2 verilink 551V models running absolutely flawlessly for 10 months now. From my perspective it's an excellent unit. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092307110800> Received: from CC5.BBN.COM by SRI-NIC.ARPA with TCP; Wed 23 Sep 87 10:55:36-PDT To: AFDDN.TCP-IP@GUNTER-ADAM.ARPA cc: tcp-ip@SRI-NIC.ARPA, malis@CC5.BBN.COM Subject: Re: Can of worms revisited In-reply-to: Your message of 23 Sep 87 10:55:51 -0500. Date: Wed, 23 Sep 87 13:51:08 -0400 From: Andy Malis Darrel, I'm afraid I'm not going to be able to be much of a help. You really are going to have to get the billing algorithm from DCA. The PSN is quite flexible in what it reports with regards to host traffic. For accounting purposes, it reports both octet and "segment" counts, where a segment is a configurable (power of 2) number of octets. When a host sends a message (X.25 "packet"), the number of octets and segments in that message are added to running totals (a partial segment counts as a segment), and these running totals are periodically reported to the MC. Thus, what gets reported and billed depends on the billing algorithm and the PSN configuration settings used by DCA. Regards, Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709240855.AA11291@ucbvax.Berkeley.EDU] <1987092307555100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: AFDDN.TCP-IP@GUNTER-ADAM.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Can of worms revisited Message-ID: <8709240855.AA11291@ucbvax.Berkeley.EDU> Date: Wed, 23-Sep-87 11:55:51 EDT Article-I.D.: ucbvax.8709240855.AA11291 Posted: Wed Sep 23 11:55:51 1987 Date-Received: Sat, 26-Sep-87 10:17:33 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 20 To anyone who might know, especially Andy or Sharon, I've been trying to get someone(mostly DCA) to specify to me exactly what a "packet" is in terms of the billing algorithm. Since the billing algorithm is based on the traffic stats gathered by the PSN's, I'm really asking what are the packets reflected on the throughput reports. I make the differentiation between X.25 packets which can be anywhere from 128 to 1024 bytes, and the subnet "packets" passed between E-to-E in the PSNs. If memory serves me, the EE's break "messages" into 128 byte subnet "packets" for sending thru the backbone. X.25 packets, (basic that is) are viewed as messages, therefore a 1024 byte X.25 packet is 8 subnet "packets". With standard X.25, your message is a complete packet sequence and is actually now the length of you IP datagrams. But the the datagram is still broken into 128 byte "packets" by EE. If all this is true then a you could calculate the minimum number of "packets" to send x number of bytes thru the network. Not really that easy, but a place to start. Darrel Beach AF DDN PMO ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709240904.AA11398@ucbvax.Berkeley.EDU] <1987092308063400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: OPRBBDM@TCSVM.BITNET.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: DSU/CSU units Message-ID: <8709240904.AA11398@ucbvax.Berkeley.EDU> Date: Wed, 23-Sep-87 12:06:34 EDT Article-I.D.: ucbvax.8709240904.AA11398 Posted: Wed Sep 23 12:06:34 1987 Date-Received: Sat, 26-Sep-87 10:18:14 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 I'm sorry to hear about your Verilink problems. Were I suffering the same difficulty I surely would not have recommended the box. One question, are you span powered? South Central Bell (in Louisiana) provides T-1 via fiber only, so my boxes are powered by standalone 48 v. power supplies from Tellabs. You may be taking some hits on the span if that's where your D.C is coming from. We test our line with firebird sets, and they show zero errors. The gear the phone company uses is not nearly as sophisticated (at laest in our region). I've had 2 verilink 551V models running absolutely flawlessly for 10 months now. From my perspective it's an excellent unit. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]23-Sep-87.13:18:15.CERF] <1987092309180000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Can of worms revisited Message-ID: <[A.ISI.EDU]23-Sep-87.13:18:15.CERF> Date: Wed, 23-Sep-87 13:18:00 EDT Article-I.D.: <[A.ISI.EDU]23-Sep-87.13:18:15.CERF> Posted: Wed Sep 23 13:18:00 1987 Date-Received: Sat, 26-Sep-87 11:32:14 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 38 Public data nets in the U.S. and in other countries, utilizing X.25 and X.75, have chosen an accounting fiction, the "segment" as a way to deal with variance in actual and in maximum packet sizes. Exchange tariffs and user tariffs are based on the number of segments sent or received by a particular pair of parties. Typically the bill is accumulated against the originator of the virtual circuit although reverse charging is permitted; usually only domestically as international reverse charge calls are sometimes hard to collect for. The public network administration announces the segment size (in octets) and the charges are for the number of octets sent on a given virtual circuit. If a packet contains less than one segment's worth or an integral number plus a fraction of segments, the accounting is rounded up to the nearest segment for that packet. Between administrations that normally charge for service using DIFFERENT segment sizes, there is an agreement at the X.75 interconnect on an interexchange segment size for purposes of calculating balances due between each administration. Charges to users are up to each domestic public data net - some stick with their standard domestic segment size and some use the smaller of the domestic and the size for going to the target administration. This assumes, of course, that the target administration's network is "one hop" from the originating network. There are cases of transit nets, and these require 3-way negotiations to determine how much of the user charges will be shared by each administration. In the case of datagram systems, similar segment size accounting methods can be used - binding the charges to a particular user rather than to a host might be the easier path since datagrams often don't have user level identifying information in them.l Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092309180001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 23 Sep 87 10:20:08-PDT Date: 23 Sep 1987 13:18-EDT Sender: CERF@A.ISI.EDU Subject: Re: Can of worms revisited From: CERF@A.ISI.EDU To: AFDDN.TCP-IP@GUNTER-ADAM.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]23-Sep-87 13:18:15.CERF> In-Reply-To: The message of 23 Sep 1987 10:55:51 CDT from AFDDN.TCP-IP@GUNTER-ADAM.ARPA Public data nets in the U.S. and in other countries, utilizing X.25 and X.75, have chosen an accounting fiction, the "segment" as a way to deal with variance in actual and in maximum packet sizes. Exchange tariffs and user tariffs are based on the number of segments sent or received by a particular pair of parties. Typically the bill is accumulated against the originator of the virtual circuit although reverse charging is permitted; usually only domestically as international reverse charge calls are sometimes hard to collect for. The public network administration announces the segment size (in octets) and the charges are for the number of octets sent on a given virtual circuit. If a packet contains less than one segment's worth or an integral number plus a fraction of segments, the accounting is rounded up to the nearest segment for that packet. Between administrations that normally charge for service using DIFFERENT segment sizes, there is an agreement at the X.75 interconnect on an interexchange segment size for purposes of calculating balances due between each administration. Charges to users are up to each domestic public data net - some stick with their standard domestic segment size and some use the smaller of the domestic and the size for going to the target administration. This assumes, of course, that the target administration's network is "one hop" from the originating network. There are cases of transit nets, and these require 3-way negotiations to determine how much of the user charges will be shared by each administration. In the case of datagram systems, similar segment size accounting methods can be used - binding the charges to a particular user rather than to a host might be the easier path since datagrams often don't have user level identifying information in them.l Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]23-Sep-87.13:22:49.CERF] <1987092309220000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: DSU/CSU units Message-ID: <[A.ISI.EDU]23-Sep-87.13:22:49.CERF> Date: Wed, 23-Sep-87 13:22:00 EDT Article-I.D.: <[A.ISI.EDU]23-Sep-87.13:22:49.CERF> Posted: Wed Sep 23 13:22:00 1987 Date-Received: Sat, 26-Sep-87 11:02:50 EDT References: <876@saturn.ucsc.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Sorry to seem dense, but I thought the idea behind 8ZBS was to force some ones in the stream to maintain sync - but that this was done in a way which the telco did NOT see anything funny. The telco equipment usually requires that there be some 1s in the data stream every so often to assure clock synchronization. If a data stream threatens to send a long sequence of zeros (as a crypto stream might), one puts in a gadget that will convert 8 zeroes into a different bit pattern, and on the receiving side, turn them back into zeroes. Why would the telco see that as lots of line errors? Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709240147.AA02675@ucbvax.Berkeley.EDU] <1987092309250000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jerry@TWG.ARPA ("Jerry Scott") Newsgroups: comp.protocols.tcp-ip Subject: Put me on the list Message-ID: <8709240147.AA02675@ucbvax.Berkeley.EDU> Date: Wed, 23-Sep-87 13:25:00 EDT Article-I.D.: ucbvax.8709240147.AA02675 Posted: Wed Sep 23 13:25:00 1987 Date-Received: Sat, 26-Sep-87 10:48:02 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "Jerry Scott" Organization: The ARPA Internet Lines: 8 Sorry to bother the net with this but requests to tcp-ip-request seem to not be heard. Please add address to this distribution list. Thanks, Jerry Scott ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12336976020.67.ROODE@BIONET-20.ARPA] <1987092311531900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROODE@BIONET-20.ARPA (David Roode) Newsgroups: comp.protocols.tcp-ip Subject: PC Telnet with Tek Graphics emulator Message-ID: <12336976020.67.ROODE@BIONET-20.ARPA> Date: Wed, 23-Sep-87 15:53:19 EDT Article-I.D.: BIONET-2.12336976020.67.ROODE Posted: Wed Sep 23 15:53:19 1987 Date-Received: Sat, 26-Sep-87 10:59:31 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 We have need of a PC Telnet implementation which includes having the terminal emulation component cover Tektronics 4014-style graphics. Since this is a quite common feature in terminal emulators for an RS232 port, it seems reasonable that it would be available for TCP Telnet as well. Does anyone have any pointers? ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [499@hubcap.UUCP] <1987092312191900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hubcap@hubcap.UUCP (Mike S Marshall) Newsgroups: comp.protocols.tcp-ip Subject: VMS 4.6 and WIN/TCP Message-ID: <499@hubcap.UUCP> Date: Wed, 23-Sep-87 16:19:19 EDT Article-I.D.: hubcap.499 Posted: Wed Sep 23 16:19:19 1987 Date-Received: Sat, 26-Sep-87 04:47:25 EDT Organization: Clemson University, Clemson, SC Lines: 12 Keywords: soothing the sysadmin's nerves... We received VMS 4.6 the other day. We run Wollongonk's WIN/TCP 3.0 on our VMS VAXen. I am responsible for WIN/TCP's operation. The sysadmin for the VMS machines is trying to anticipate what might break when she does the OS upgrade. She asked me to find out what I could about the compatibility of WIN/TCP and VMS 4.6. So now I'm asking you guys... has anyone that is using WIN/TCP upgraded to VMS 4.6? If so, did you experience any problems? thanks in advance. -Mike Marshall hubcap@hubcap.clemson.edu ...!hubcap!hubcap ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709240237.AA02350@monk.proteon.com] <1987092318375500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jas@MONK.PROTEON.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: DSU/CSU units Message-ID: <8709240237.AA02350@monk.proteon.com> Date: Wed, 23-Sep-87 22:37:55 EDT Article-I.D.: monk.8709240237.AA02350 Posted: Wed Sep 23 22:37:55 1987 Date-Received: Sat, 26-Sep-87 10:04:20 EDT References: <[A.ISI.EDU]23-Sep-87.13:22:49.CERF> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 27 (This may be a little rusty, since I'm not near my PUB's, but I think I've got the spirit, if not the letter, right.) T1 coding is trilevel, with levels I will call -1, 0, and +1. A bit of "zero" is always represented as 0. A bit "one" of will will be represented as -1 if the last "one" was +1, and as +1 if the last "one" was -1. T1 uses regenerative reclocking repeaters along the line. They require flux transitions to ge the clock out of. If they don't get enough, they lose it. To get transitions, you've got to send some "one"'s. This is why the rule of no more than 7 (?) "zero"'s in a row. B8ZS avoids this by putting a code violation in the bit cell for the 8th "zero". Thus, if the last "one" was -1, the 8th "zero" will be -1, and if the last "one" was +1, the 8th "zero" will be +1. This offends Central Offices, who constantly check for code violations. This one way they decide the line is sick. The nation may not be fully B8ZS safe for another decade. Many CSU/DSU's offer to run without B8ZS. They use different schemes to put your raw sync data on the T1 line without needing B8ZS to provide data transparency. Their price is usually correlated with how many bits they waste doing this, and how high a clock rate you get at the sync (RS-449) interface. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709240330.AA04973@ucbvax.Berkeley.EDU] <1987092320232700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: malis@CC5.BBN.COM (Andy Malis) Newsgroups: comp.protocols.tcp-ip Subject: Re: Can of worms revisited Message-ID: <8709240330.AA04973@ucbvax.Berkeley.EDU> Date: Thu, 24-Sep-87 00:23:27 EDT Article-I.D.: ucbvax.8709240330.AA04973 Posted: Thu Sep 24 00:23:27 1987 Date-Received: Sat, 26-Sep-87 11:02:28 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Darrel, I'm afraid I'm not going to be able to be much of a help. You really are going to have to get the billing algorithm from DCA. The PSN is quite flexible in what it reports with regards to host traffic. For accounting purposes, it reports both octet and "segment" counts, where a segment is a configurable (power of 2) number of octets. When a host sends a message (X.25 "packet"), the number of octets and segments in that message are added to running totals (a partial segment counts as a segment), and these running totals are periodically reported to the MC. Thus, what gets reported and billed depends on the billing algorithm and the PSN configuration settings used by DCA. Regards, Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [259354.870924.JBVB@AI.AI.MIT.EDU] <1987092320554600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: PCP/IP Message-ID: <259354.870924.JBVB@AI.AI.MIT.EDU> Date: Thu, 24-Sep-87 00:55:46 EDT Article-I.D.: AI.259354.870924.JBVB Posted: Thu Sep 24 00:55:46 1987 Date-Received: Sat, 26-Sep-87 11:00:05 EDT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 From: BDK%UNB.BITNET@wiscvm.wisc.edu As a potential new user of TCP and IP I would like to get some info on PCP/IP. What is it and where can I get a copy? I am guessing that you meant "PC/IP". This is a set of user TCP/IP utilities for MS/DOS PCs originally written at MIT some years back, and released as freeware. You can get a version from the MIT Microcomputer Office (source or binary, but the source requires a cross-compiler which you need a 4BSD source license to obtain). You can get another version from CMU, ported to Microsoft C and with various improvements. You can get commercialized, enhanced & supported versions of it from various suppliers (we're proud of the ancestry of ours...). Most of them are listed in the "Vendor's Guide", available electronically or printed from the people at SRI. You can get lots more information by joining the mailing list devoted to PC/IP and its descendants: pc-ip@huey.udel.edu. James VanBokkelen FTP Software Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709231713.AA26644@devvax.TN.CORNELL.EDU] <1987092401122000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: fedor@DEVVAX.TN.CORNELL.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: gated 1.3.1 available now! Message-ID: <8709231713.AA26644@devvax.TN.CORNELL.EDU> Date: Thu, 24-Sep-87 05:12:20 EDT Article-I.D.: devvax.8709231713.AA26644 Posted: Thu Sep 24 05:12:20 1987 Date-Received: Sat, 26-Sep-87 10:18:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 25 The newest version of gated can be obtained by anonymous FTP from devvax.tn.cornell.edu. The distribution is in the file ~ftp/pub/gated/gated.tar or compressed as ~ftp/pub/gated/gated.tar.Z So my little VAX-750 doesn't get bogged down, I also have it available on nic.nyser.net. Same access method and same files. If for some reason you can't grab gated over the internet, UUCP could be arranged, but until I hear some requests, I won't worry about it. Maybe I'll post to mod.sources or something..... read the README file for info on joining the bugs/update gated mailing list. Cheers, Mark P.S. those of you which sent me tapes, they were sent out. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709241203.AA14116@ucbvax.Berkeley.EDU] <1987092403430000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BEAME@MCMASTER.BITNET.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: PC Telnet with Tek Graphics emulator Message-ID: <8709241203.AA14116@ucbvax.Berkeley.EDU> Date: Thu, 24-Sep-87 07:43:00 EDT Article-I.D.: ucbvax.8709241203.AA14116 Posted: Thu Sep 24 07:43:00 1987 Date-Received: Sat, 26-Sep-87 12:57:14 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Many people require terminal emulators that exist in the RS232 realm to work on Telnet. One solution to this problem is the product BWCOM from Beame & Whiteside software Ltd. . It allows interupt driven RS232 terminal emulators to run Telnet over an ethernet. The serial terminal emulator thinks it's talking to a Hayes compatible modem. - Carl Beame BEAME@MCMASTER.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092403430001> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Thu 24 Sep 87 04:57:47-PDT Received: from MCMASTER.BITNET by wiscvm.wisc.edu ; Thu, 24 Sep 87 06:57:16 CDT Date: Thu, 24 Sep 87 07:43 EDT From: Subject: Re: PC Telnet with Tek Graphics emulator To: TCP-IP@SRI-NIC.ARPA X-Original-To: TCP-IP@SRI-NIC.ARPA, BEAME Many people require terminal emulators that exist in the RS232 realm to work on Telnet. One solution to this problem is the product BWCOM from Beame & Whiteside software Ltd. . It allows interupt driven RS232 terminal emulators to run Telnet over an ethernet. The serial terminal emulator thinks it's talking to a Hayes compatible modem. - Carl Beame BEAME@MCMASTER.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]24-Sep-87.10:16:29.CERF] <1987092406160000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: DSU/CSU units Message-ID: <[A.ISI.EDU]24-Sep-87.10:16:29.CERF> Date: Thu, 24-Sep-87 10:16:00 EDT Article-I.D.: <[A.ISI.EDU]24-Sep-87.10:16:29.CERF> Posted: Thu Sep 24 10:16:00 1987 Date-Received: Sat, 26-Sep-87 17:04:59 EDT References: <8709240237.AA02350@monk.proteon.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 In the early days of digital voice, when T1 was invented, I recall that every 8th bit of each 24 channel sequence (192 bits total) was a 1 for signalling/sync purposes. That coding gave you only 56 kb/s of digital information, but avoided any problems with regeneration. Over time, the need for such signalling went down (after all, 1/8 of each channel was 8 kb/s which is a lot just for signalling). It sounds as if the coding trinary coding scheme didn't account for arbitrary data passing through repeaters. Sigh. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709241442.AA16268@ucbvax.Berkeley.EDU] <1987092406202100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) Newsgroups: comp.protocols.tcp-ip Subject: Re: Can of worms revisited Message-ID: <8709241442.AA16268@ucbvax.Berkeley.EDU> Date: Thu, 24-Sep-87 10:20:21 EDT Article-I.D.: ucbvax.8709241442.AA16268 Posted: Thu Sep 24 10:20:21 1987 Date-Received: Sat, 26-Sep-87 16:50:48 EDT References: <[A.ISI.EDU]23-Sep-87.13:18:15.CERF> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 39 Vint-- Shades of the October, 1971 Network Working Group meeting! Not positive you were there (seem to think so, but Early Middle Age does funny things to the memory, as we saw the other week in re the "But My NCP Costs $500 a Day..." RFC), so for the List's benefit at least and maybe yours as well, the relevant incident was that at one point Larry Roberts said that ARPA's intention was eventually to be charging 30 cents a kilo-packet and Frank Heart called out "Don't you mean 30 cents a mega-bit?"; Larry replied that he really maent 30 cents a kilo-packet and there was a small round of applause from those of us whose Hosts were line-at-a-time rather than character-at-a-time by nature. (For the benefit of non-oldtimers, Larry was head of ARPA's Information Processing Techniques [or Technology--but I always got confused over that even before EMA] Office at the time [a/k/a Our Sponsor] and Frank was either still a Division Head at BBN or maybe already a VP [I think the former, but ...].) It sure sounds to me as if the time has finally come when we really have to deal with the Remote Controlled Echoing issue, in light of the apparent return of the point of view which holds that it doesn't matter whether you've got one word or several pages in the metaphorical envelope, it still requires a metaphorical stamp. As you know (but as I'm not sure it's proper to go into detail about on the List), I'm not in a position to volunteer to head up an ad hoc working group on RCTE (T for Terminal, as I recall) at present, but I'd certainly urge somebody to step forward and I'd be glad to offer whatever help I'm in a position to offfer when it gets going, or even, if it makes the pot sweeter, to offer to stay out of it entirely, if that's what it takes to get a volunteer. If Dave Clark is watching, perhaps he'd like to do the convening, or mabye it's within the purview of one of the existing task forces, but in any event it does seem that if there's a clear and present danger of having to pay per character for all the character-at-a-time transmissions it's incumbent on us to decrease the number of those transmissions. cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092406202101> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Thu 24 Sep 87 07:23:22-PDT Date: 24 Sep 1987 10:20:21 EDT Subject: Re: Can of worms revisited From: Michael Padlipsky To: CERF@A.ISI.EDU cc: AFDDN.TCP-IP@GUNTER-ADAM.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: <[A.ISI.EDU]23-Sep-87 13:18:15.CERF> Vint-- Shades of the October, 1971 Network Working Group meeting! Not positive you were there (seem to think so, but Early Middle Age does funny things to the memory, as we saw the other week in re the "But My NCP Costs $500 a Day..." RFC), so for the List's benefit at least and maybe yours as well, the relevant incident was that at one point Larry Roberts said that ARPA's intention was eventually to be charging 30 cents a kilo-packet and Frank Heart called out "Don't you mean 30 cents a mega-bit?"; Larry replied that he really maent 30 cents a kilo-packet and there was a small round of applause from those of us whose Hosts were line-at-a-time rather than character-at-a-time by nature. (For the benefit of non-oldtimers, Larry was head of ARPA's Information Processing Techniques [or Technology--but I always got confused over that even before EMA] Office at the time [a/k/a Our Sponsor] and Frank was either still a Division Head at BBN or maybe already a VP [I think the former, but ...].) It sure sounds to me as if the time has finally come when we really have to deal with the Remote Controlled Echoing issue, in light of the apparent return of the point of view which holds that it doesn't matter whether you've got one word or several pages in the metaphorical envelope, it still requires a metaphorical stamp. As you know (but as I'm not sure it's proper to go into detail about on the List), I'm not in a position to volunteer to head up an ad hoc working group on RCTE (T for Terminal, as I recall) at present, but I'd certainly urge somebody to step forward and I'd be glad to offer whatever help I'm in a position to offfer when it gets going, or even, if it makes the pot sweeter, to offer to stay out of it entirely, if that's what it takes to get a volunteer. If Dave Clark is watching, perhaps he'd like to do the convening, or mabye it's within the purview of one of the existing task forces, but in any event it does seem that if there's a clear and present danger of having to pay per character for all the character-at-a-time transmissions it's incumbent on us to decrease the number of those transmissions. cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709241518.AA03643@monk.proteon.com] <1987092407181600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jas@MONK.PROTEON.COM (John A. Shriver) Newsgroups: comp.protocols.tcp-ip Subject: DSU/CSU units Message-ID: <8709241518.AA03643@monk.proteon.com> Date: Thu, 24-Sep-87 11:18:16 EDT Article-I.D.: monk.8709241518.AA03643 Posted: Thu Sep 24 11:18:16 1987 Date-Received: Sat, 26-Sep-87 17:36:26 EDT References: <[A.ISI.EDU]24-Sep-87.10:16:29.CERF> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 18 Now that I'm at my office, I see I goofed a little on B8ZS. There are two complex patterns that replace the 8 "zero"'s, depending on the polarity of the last "one". If the last "one" was +1, then you send 0,0,0,+1,-1,0,-1,+1. If the last "one" was -1, you send 0,0,0,-1,+1,0,+1,-1. The fourth and seventh positions are bipolar violations. This is better than what I described before, as it gives you a lot more flux changes (4 vs. 1). I beleive the eigth bit in voice use is used for signalling (on-hook/off-hook), but not to provide one's density. It appears that the one's density is provided by having the PCM voice not have any voltage that comes out as seven "zero"s. (Or at least making this very infrequent.) However, the 56KB of DDS service definitely comes from stuffing that eighth bit as a "one". This is also what the cheaper DSU/CSU's do. For further reference, see AT&T PUB 62411. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [520@louie.udel.EDU] <1987092409152300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: garrett@udel.EDU (Joel Garrett) Newsgroups: comp.protocols.tcp-ip Subject: Re: PC Telnet with Tek Graphics emulator Message-ID: <520@louie.udel.EDU> Date: Thu, 24-Sep-87 13:15:23 EDT Article-I.D.: louie.520 Posted: Thu Sep 24 13:15:23 1987 Date-Received: Sat, 26-Sep-87 17:01:09 EDT References: <8709241203.AA14116@ucbvax.Berkeley.EDU> Reply-To: garrett@udel.EDU (Joel Garrett) Organization: University of Delaware Lines: 17 Summary: More info on B&W Ltd, please... In article <8709241203.AA14116@ucbvax.Berkeley.EDU> BEAME@MCMASTER.BITNET writes: >Many people require terminal emulators that exist in the RS232 realm to >work on Telnet. One solution to this problem is the product BWCOM from >Beame & Whiteside software Ltd. . It allows interupt driven RS232 >terminal emulators to run Telnet over an ethernet. The serial terminal >emulator thinks it's talking to a Hayes compatible modem. > > - Carl Beame > BEAME@MCMASTER.BITNET This looks like a very interesting product. How could one get in touch with B&W Ltd. to get more info and also possibly purchase the product? Joel Garrett garrett@udel.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709242204.AA10494@topaz.rutgers.edu] <1987092414045200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: DSU/CSU units Message-ID: <8709242204.AA10494@topaz.rutgers.edu> Date: Thu, 24-Sep-87 18:04:52 EDT Article-I.D.: topaz.8709242204.AA10494 Posted: Thu Sep 24 18:04:52 1987 Date-Received: Sat, 26-Sep-87 18:02:39 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 8ZBS generates bipolar violations of a specific kind. Some telco equipment allows it and some does not. For single-channel T1 (i.e. two IP gateways that want the whole bandwidth of a T1 connecting them), we have used a gadget from Digilink that I call a T1-izer. It takes a vanilla synchronous signal, and supplies everything that is needed to pass it through T1. There are a number of switches that control the encoding. You can select 8ZBS, if your telco can hack that, or a more convservative encoding if they can't. (There is of course a slight benefit in terms of line speed if you use 8ZBS.) THis also has a DSU/CSU builtin. (However we more typically use Avanti equipment, because we need to multiplex several channels on one T1 line.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [259899.870924.JBVB@AI.AI.MIT.EDU] <1987092418482200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: PC Telnet with Tek Graphics emulator Message-ID: <259899.870924.JBVB@AI.AI.MIT.EDU> Date: Thu, 24-Sep-87 22:48:22 EDT Article-I.D.: AI.259899.870924.JBVB Posted: Thu Sep 24 22:48:22 1987 Date-Received: Sat, 26-Sep-87 16:08:28 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 17 Our PC/TCP comes with "glass" versions of Telnet and Rlogin. These contain no terminal emulation of their own, and do all I/O via the MS/DOS console devie (CON). If a terminal-emulating device driver is present (like ANSI.SYS), whatever emulation it provides is passed the Telnet data stream, and keyboard input gets passed through it too. We don't sell any drivers to go with this, but we do have one public-domain one that we provide on request (for an HP26?? terminal), and there is at least one commercial Tek emulator (from Grafpoint, it does a 4105) which is known to work with our stuff. NANSI works, too, and I would expect anything else that loads as a device driver for CON to work (subject to the lamentable fact that very few Telnets are able to pass 8-bit data). James B. VanBokkelen spdcc!ftp!jbvb@harvard.harvard.edu FTP Software Inc. (617) 868-4878 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [350@sering.cwi.nl] <1987092503005700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: piet@cwi.nl (Piet Beertema) Newsgroups: comp.protocols.tcp-ip Subject: Re: Can of worms revisited Message-ID: <350@sering.cwi.nl> Date: Fri, 25-Sep-87 07:00:57 EDT Article-I.D.: sering.350 Posted: Fri Sep 25 07:00:57 1987 Date-Received: Sat, 26-Sep-87 20:08:17 EDT References: <[A.ISI.EDU]23-Sep-87.13:18:15.CERF> Organization: CWI, Amsterdam Lines: 12 ...have chosen an accounting fiction, the "segment" as a way to deal with variance in actual and in maximum packet sizes. The public network administration announces the segment size (in octets) and the charges are for the number of octets sent on a given virtual circuit. Note that the accounting entity "segment" comprises pure user data only, no headers and other stuff. -- Piet Beertema, CWI, Amsterdam (piet@cwi.nl) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092510360000> Received: from twg.arpa by SRI-NIC.ARPA with TCP; Fri 25 Sep 87 17:41:19-PDT Date: 25 Sep 87 17:36:00 PDT From: "Dave Crocker" Subject: RCTE To: "tcp-ip" Reply-To: "Dave Crocker" Reviving the Remote Controlled Transmission and Echoing telnet option is an interesting idea. Certainly SOMETHING needs to be done. Part of the problem with the original protocol (my very first effort and it looks like it) was that it was not rich enough in maintaining synchronization. Stepping back a bit, it requires that the serving host allow the application to specify what kinds of characters are "interesting" (on the theory that the sending host can aggregate all the characters up to the interesting one and then send them in a batch). RCTE was based upon John Davidson's (then of Univ. of Hawaii) observation that Tenex (a derivative of which now runs on Decsystem-20s) had just such a feature. Unfortunately, it is not common to some well-known operating system. Even more interesting is the thought that such a protocol should be more ambitious. RCTE does not know anything about the terminal or the semantics of the session. A "display-oriented" protocol could be much more powerful. John Day, then of Univ of Illinois, began a campaign for such a telnet option and continued it for quite some time. I believe that a version is still in the protocol books. Perhaps we should dust it off and see why it shouldn't be aggressively implemented. Dave ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709251938.AA12356@gateway.mitre.org] <1987092511382900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya) Newsgroups: comp.protocols.tcp-ip Subject: request for peer review Message-ID: <8709251938.AA12356@gateway.mitre.org> Date: Fri, 25-Sep-87 15:38:29 EDT Article-I.D.: gateway.8709251938.AA12356 Posted: Fri Sep 25 15:38:29 1987 Date-Received: Sun, 27-Sep-87 02:12:39 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 99 To whom it may concern (and a plea for help)...................... I am working on a set of new techniques for dynamic routing in very large networks, called Landmark Routing. Anybody at the July IETF meeting saw a presentation of some of this work. I have just finished a rough draft of a major piece of work that describes, mostly at medium to high level, how all of Landmark Routing works. (The previous document, which a lot of people have seen, is full of fairly nitty-gritty details about one small aspect of Landmark Routing--the Landmark Hierarchy). I am looking for people to read the paper and give me feedback. I hope that there is a varied collection of people out there that would be interested in this work--partly because it contains a lot of new ideas, and partly because there is a reasonably good chance that implementations of it will find their way into the internet in the near future (one year at best). Landmark Routing basically is a set of protocols and algorithms that allow for fully automated routing in arbitrarily large networks and internets. Its main feature is that it automatically configures its own hierarchy for dealing with large numbers of nodes--no preassigned addresses are necessary! To deal with changing addresses, it offers a general, fully distributed name-to-address binding scheme, which we have dubbed Assured Destination Binding. As a fallout of this, Landmark Routing can handle any number of mobile hosts. We have also incorporated the concept of administrative boundaries into the scheme. This allows messages to stay within a pre-defined boundary, prevents other messages from going through the boundary (if desired), and allows a fair amount of autonomy between different groups. The paper itself, called "Landmark Routing: Architecture, Algorithms, and Issues," is long; over 140 pages. However, don't let this lower your expectations about the quality of the work. Unlike many long papers, I don't think any of this thing is content-free. (Believe me, if I could fit all of it into one double spaced page, I would). Because of the length, I would only expect people to give substantive review individual sections. There are 5 major sections (not including the section that overviews the main idea behind Landmark Routng). Although a general understanding of Landmark Routing is needed to help understand any section, they all pretty much stand alone. Therefore, one could realistically give substantive review to any one section without reading the whole thing in gory detail. Let me outline each section, so that people can get an idea of whether they want to read it. I am only interested in hearing from people who will give it a real critical review. Section 2 describes the basic idea behind Landmark Routing. I don't need any review of this section. Section 3 describes the routing protocol I intend to use with Landmark Routing (the way it is architected, multiple and/or different routing protocols can be used, as long as they are of the distance-vector (i.e., Bellman-Ford, Old ARPANET, etc.) variety). Don't worry about the count-to-infinity business. This section contains a simple and efficient fix to count-to-infinity that has INSTANT convergence to new routes given bad news. (Even good-ole SPF doesn't have instant convergence.) This is because the alternate route is pre-primed even before bad news comes along. We call this scheme Alternate-path Distance-vector Routing. The alternate route also provides some nice path splitting to boot. Section 4 describes how the hierarchy is maintained and adjusted in the face of topology changes, including merging networks together. Section 5 describes the administrative autonomy and trust scheme that we employ, called Administrative Zones. It provides some of what Autonomous Systems provide. Section 6 describes the name-to-address binding technique mentioned above. This technique works with a completely flat name space (as long as names are unique), and can be distributed among as many or as few nodes as desired. Finally, section 7 provides a lot of miscellaneous, include implementation ideas, transition issues, address structures, how to configure across large, non-broadcast subnetworks, and the like. I should note that this implementation will be for ISO only (the DoD IP address is just too small), but will be able to handle DoD IP packets. As such, it will be useful during transition. Also, most of the implementation will run at the application layer. I GREATLY appreciate any help people wish to offer. Thanks in advance.................. Paul Tsuchiya tsuchiya@gateway.mitre.org The MITRE Corp. tsuchiya@mitre-gateway.arpa P.S. (Sorry for those of you who received this over several lists) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870925-141936-17047@Xerox] <1987092513192300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: weiser.pa@XEROX.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: newer (bug fixed) 4.3bsd tcp for Sun OS 3.3 available Message-ID: <870925-141936-17047@Xerox> Date: Fri, 25-Sep-87 17:19:23 EDT Article-I.D.: Xerox.870925-141936-17047 Posted: Fri Sep 25 17:19:23 1987 Date-Received: Sun, 27-Sep-87 03:32:47 EDT References: <8706272026.AA16055@lbl-csam.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 20 Although Van Jacobson modestly states you don't want to run his code if you have Sun 3.4, I continue to measure large performance differences in extreme cases. I get the following times for transferring 10 megabytes memory-to-memory (in other words, the client generates the bytes from thin air, and the server puts them all into the same buffer): 33 secs SunOs 3.4 23 secs The Berkeley 4.3 + fixes courtesy of Van Jacobson, on top of 3.3. This times are measured from Sun-3/260 to Sun-3/260 on the same ethernet. Base load on the ethernet was 10-20%, so conceivably these times could improve a bit. I suspect that what accounts for the difference is that the SunOS 3.4 never seems to generate an ethernet packet larger 576 bytes or so when operated through tcp, even though with UDP it generates the full 1500+ byte packets. netstat -i gives an MTU of 1500. -mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709252124.AA08822@umd5.UMD.EDU] <1987092513242600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: davidc@UMD5.UMD.EDU Newsgroups: comp.protocols.tcp-ip Subject: Survey of people working on TCP/IP for the PC Message-ID: <8709252124.AA08822@umd5.UMD.EDU> Date: Fri, 25-Sep-87 17:24:26 EDT Article-I.D.: umd5.8709252124.AA08822 Posted: Fri Sep 25 17:24:26 1987 Date-Received: Sun, 27-Sep-87 05:24:48 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 I was wondering who is actively working on TCP/IP for the PC and which flavor (CMU, MIT, commercial, etc). Please send replies directly to me and I'll summarize if there is any interest. -drc ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709260045.AA22857@ucbvax.Berkeley.EDU] <1987092516360000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dcrocker@TWG.ARPA ("Dave Crocker") Newsgroups: comp.protocols.tcp-ip Subject: RCTE Message-ID: <8709260045.AA22857@ucbvax.Berkeley.EDU> Date: Fri, 25-Sep-87 20:36:00 EDT Article-I.D.: ucbvax.8709260045.AA22857 Posted: Fri Sep 25 20:36:00 1987 Date-Received: Sun, 27-Sep-87 06:56:47 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "Dave Crocker" Distribution: world Organization: The ARPA Internet Lines: 24 Reviving the Remote Controlled Transmission and Echoing telnet option is an interesting idea. Certainly SOMETHING needs to be done. Part of the problem with the original protocol (my very first effort and it looks like it) was that it was not rich enough in maintaining synchronization. Stepping back a bit, it requires that the serving host allow the application to specify what kinds of characters are "interesting" (on the theory that the sending host can aggregate all the characters up to the interesting one and then send them in a batch). RCTE was based upon John Davidson's (then of Univ. of Hawaii) observation that Tenex (a derivative of which now runs on Decsystem-20s) had just such a feature. Unfortunately, it is not common to some well-known operating system. Even more interesting is the thought that such a protocol should be more ambitious. RCTE does not know anything about the terminal or the semantics of the session. A "display-oriented" protocol could be much more powerful. John Day, then of Univ of Illinois, began a campaign for such a telnet option and continued it for quite some time. I believe that a version is still in the protocol books. Perhaps we should dust it off and see why it shouldn't be aggressively implemented. Dave ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709260145.AA22824@spdcc.COM] <1987092517044500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jbvb@ftp.UUCP (James Van Bokkelen) Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP for HP 3000s? Message-ID: <8709260145.AA22824@spdcc.COM> Date: Fri, 25-Sep-87 21:04:45 EDT Article-I.D.: spdcc.8709260145.AA22824 Posted: Fri Sep 25 21:04:45 1987 Date-Received: Sun, 27-Sep-87 07:07:59 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 I'm pretty sure HP doesn't have one. Does anything exist in the public domain, or from another vendor? If respondents think there will be enough responses to annoy the list, send them to me, and I will summarize. spdcc!ftp!jbvb@harvard.harvard.edu James B. VanBokkelen FTP Software Inc. 501 Cambridge St. Cambridge, MA 02141 (617) 868-4878 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092520570000> Received: from bluto.scc.com by SRI-NIC.ARPA with TCP; Fri 25 Sep 87 23:06:28-PDT Date: 26 Sep 87 01:57:00 EST From: "GBURG::ENGER" Subject: RCTE functionality To: "dcrocker" cc: tcp-ip@sri-nic.arpa,enger Reply-To: "GBURG::ENGER" Dave: It is my impression that DEC's CTERM protocol provides at least some of the desired functionality. Bob ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709260609.AA26652@ucbvax.Berkeley.EDU] <1987092522570000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: enger%gburg.DECnet@BLUTO.SCC.COM ("GBURG::ENGER") Newsgroups: comp.protocols.tcp-ip Subject: RCTE functionality Message-ID: <8709260609.AA26652@ucbvax.Berkeley.EDU> Date: Sat, 26-Sep-87 02:57:00 EDT Article-I.D.: ucbvax.8709260609.AA26652 Posted: Sat Sep 26 02:57:00 1987 Date-Received: Sun, 27-Sep-87 09:45:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "GBURG::ENGER" Distribution: world Organization: The ARPA Internet Lines: 6 Dave: It is my impression that DEC's CTERM protocol provides at least some of the desired functionality. Bob ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1756@ulowell.cs.ulowell.edu] <1987092523264200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: page@ulowell.cs.ulowell.edu (Bob Page) Newsgroups: comp.unix.questions,comp.protocols.tcp-ip Subject: route & routed info Message-ID: <1756@ulowell.cs.ulowell.edu> Date: Sat, 26-Sep-87 03:26:42 EDT Article-I.D.: ulowell.1756 Posted: Sat Sep 26 03:26:42 1987 Date-Received: Sun, 27-Sep-87 10:39:32 EDT Sender: news@ulowell.cs.ulowell.edu Reply-To: page@swan.ulowell.edu (Bob Page) Followup-To: comp.protocols.tcp-ip Distribution: world Organization: University of Lowell, Computer Science Dept. Lines: 28 Keywords: routed dmr dmc 4.3 network ifconfig Summary: Looking for advice on 4.3bsd routing problem I just added a dmr-11 to a 4.3 system, and can't talk to it. I say: ifconfig il0 inet 129.63.1.1 broadcast 129.63.1.0 -trailers netmask 0xffff0000 ifconfig dmc0 inet 128.188.230.2 128.188.230.1 -trailers netmask 0xffff0000 and after starting routed, 'netstat -rn' shows: Destination Gateway Flags Refcnt Use Interface 127.0.0.1 127.0.0.1 UH 0 14 lo0 128.188.230.1 128.188.230.2 UH 0 0 dmc0 128.188.230.2 129.63.1.1 UH 0 29 il0 129.63.1.1 129.63.1.1 U 0 198 il0 128.188 128.188.230.1 UG 0 0 dmc0 129.63 129.63.1.1 U 1 2914 il0 I can use the 129.63 network, but can't get to the 128.188 net. Routed sets up the 128.188.230.2 route via 129.63.1.1; it's not in my gateways file. I can ping my dmc at 128.188.230.2 but don't believe it; netstat shows all the traffic is going through il0. I can't talk to 128.188.230.1, and if I delete the route from 129.63.1.1 to 128.188.230.1 I can no longer ping the dmc. Any attempt results in a "Network is unreachable" message. How can I set up the routes so I can get to the 128.188 network? I'm running stock 4.3 routed. Thanks in advance. ..Bob -- Bob Page, U of Lowell CS Dept. page@ulowell.{uucp,edu,csnet} ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709270156.AA08743@ucbvax.Berkeley.EDU] <1987092606380000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BEAME@MCMASTER.BITNET Newsgroups: comp.protocols.tcp-ip Subject: Re: PC Telnet with Tek Graphics emulator Message-ID: <8709270156.AA08743@ucbvax.Berkeley.EDU> Date: Sat, 26-Sep-87 10:38:00 EDT Article-I.D.: ucbvax.8709270156.AA08743 Posted: Sat Sep 26 10:38:00 1987 Date-Received: Sun, 27-Sep-87 12:01:36 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 13 In message <2811> Udel!garrett@princeton.edu writes: >How could one get in touch with B&W Ltd. to get more info ? BWCOM is available from: Beame & Whiteside Software Ltd. 259 Fiddler's GReen Rd. Ancaster, Ontario Canada L9G 1W9 (416) 648-6556 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092606380001> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Sat 26 Sep 87 18:37:37-PDT Received: from MCMASTER.BITNET by wiscvm.wisc.edu ; Sat, 26 Sep 87 20:37:08 CDT Date: Sat, 26 Sep 87 10:38 EDT From: Subject: Re: PC Telnet with Tek Graphics emulator To: tcp-ip@sri-nic.arpa X-Original-To: tcp-ip@sri-nic.arpa, BEAME In message <2811> Udel!garrett@princeton.edu writes: >How could one get in touch with B&W Ltd. to get more info ? BWCOM is available from: Beame & Whiteside Software Ltd. 259 Fiddler's GReen Rd. Ancaster, Ontario Canada L9G 1W9 (416) 648-6556 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709270144.AA08644@ucbvax.Berkeley.EDU] <1987092607060000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BEAME@MCMASTER.BITNET Newsgroups: comp.protocols.tcp-ip Subject: Re: RCTE Message-ID: <8709270144.AA08644@ucbvax.Berkeley.EDU> Date: Sat, 26-Sep-87 11:06:00 EDT Article-I.D.: ucbvax.8709270144.AA08644 Posted: Sat Sep 26 11:06:00 1987 Date-Received: Sun, 27-Sep-87 12:01:25 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 In the SET HOST protocol (CTERM) DEC uses a one or several longwords passed from the remote side to indicate what characters the local size should terminate the QIO request. Thus echoing and deleting of characters is performed on the local end and sent only when one of the characters listed as a terminator is hit. DEC also sends a length field which will terminate the QIO and send the data when X number of characters have been sent. With the above method both "line at a time" and single character transfers can be requested. - Carl ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092607060001> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Sat 26 Sep 87 18:37:26-PDT Received: from MCMASTER.BITNET by wiscvm.wisc.edu ; Sat, 26 Sep 87 20:36:54 CDT Date: Sat, 26 Sep 87 11:06 EDT From: Subject: Re: RCTE To: tcp-ip@sri-nic.arpa X-Original-To: tcp-ip@sri-nic.arpa, BEAME In the SET HOST protocol (CTERM) DEC uses a one or several longwords passed from the remote side to indicate what characters the local size should terminate the QIO request. Thus echoing and deleting of characters is performed on the local end and sent only when one of the characters listed as a terminator is hit. DEC also sends a length field which will terminate the QIO and send the data when X number of characters have been sent. With the above method both "line at a time" and single character transfers can be requested. - Carl ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3359@b-tech.UUCP] <1987092609355400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: zeeff@b-tech.UUCP (Jon Zeeff) Newsgroups: comp.protocols.tcp-ip Subject: Re: Survey of people working on TCP/IP for the PC Message-ID: <3359@b-tech.UUCP> Date: Sat, 26-Sep-87 13:35:54 EDT Article-I.D.: b-tech.3359 Posted: Sat Sep 26 13:35:54 1987 Date-Received: Mon, 28-Sep-87 04:03:23 EDT References: <8709252124.AA08822@umd5.UMD.EDU> Reply-To: zeeff@b-tech.UUCP (Jon Zeeff) Distribution: world Organization: Branch Technology Ann Arbor, MI Lines: 11 I'm interested in tcp/ip software for the PC that includes support for FTP and the SLFP (similar but different from SLIP) serial line protocol that I believe the CMU package has. Is there such a thing? I've dome some work on making the KA9Q package speak SLFP, but with a new version out, I expect I'd have to do it over again. -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709261909.AA10409@topaz.rutgers.edu] <1987092611090900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: RCTE Message-ID: <8709261909.AA10409@topaz.rutgers.edu> Date: Sat, 26-Sep-87 15:09:09 EDT Article-I.D.: topaz.8709261909.AA10409 Posted: Sat Sep 26 15:09:09 1987 Date-Received: Sun, 27-Sep-87 11:45:44 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 33 On Unix, my impression is that we have roughly three modes: - normally software lets the system do line editing. In this mode, the terminal server could do the editing and then pass whole lines without echo - raw or cbreak mode is used by a few programs that do screen handling. It is specifically enabled by a system call, which would give the kernel a chance to trigger negotiation of a different telnet mode. THis would be full duplex, char at a time. - some screen-oriented programs are used enough that it is worth modifying them to give the terminal server instructions. Emacs is probably the best example. The main screen-oriented programs I use are emacs nad vnews. Vnews is not worth doing, I suspect, since normally the characters typed a single letters anyway, so not much improvement is to be had. I understand that Encore already has support for emacs in their terminal servers. I don't know what they are doing, but experiments were done with TOPS-20 Emacs based on the concept that Emacs should let the temrinal server echo, and should specify two things: a bit map - when any of these characteris is typed, the server should go back into char at a time mode, and let Emacs respond to that character; a count - when that many characters had been typed, ditto. The idea was that most people spent most of their time typing text at the end of a line. Emacs would set the bitmap to all of the command chars (in effect, all but printing characters), and the count to the number of characters left on the line (since Emacs will have to do some screen management when you reach the end of the line). probably Encore is in a position to make additional suggestions, but this seems a reasonable place to start. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709262205.AA05057@gwen.cs.purdue.edu] <1987092614045200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: narten@PURDUE.EDU (Thomas Narten) Newsgroups: comp.protocols.tcp-ip Subject: Re: route & routed info Message-ID: <8709262205.AA05057@gwen.cs.purdue.edu> Date: Sat, 26-Sep-87 18:04:52 EDT Article-I.D.: gwen.8709262205.AA05057 Posted: Sat Sep 26 18:04:52 1987 Date-Received: Sun, 27-Sep-87 11:42:18 EDT References: <1756@ulowell.cs.ulowell.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 72 Bob, Here is a 4.3 kernel problem that would give the symptoms you describe. I don't take credit for finding the bug, but I did remember to save it where I could find it! One way you can verify that this is really your problem is to see if things work if you *don't* run routed. Routed will time out routes for interfaces that aren't working. An interface "doesn't work" if no routed packets are received with a source address on the network. If UDP packets are being sent with an incorrect source address, this will certainly confuse routed. Thomas From: mouse@mcgill-vision.UUCP (der Mouse) Newsgroups: comp.bugs.4bsd,comp.unix.wizards Subject: 4.3bsd can mistake p-to-p interfaces Message-ID: <717@mcgill-vision.UUCP> Date: 29 Mar 87 09:26:28 GMT Organization: McGill University, Montreal Lines: 50 Posted: Sun Mar 29 04:26:28 1987 We are running mtXinu 4.3+NFS, and there is a bug in netinet/in_pcb.c. I can't be certain, but I expect that this is present in 4.3 because it is an obvious mistake once noticed; in fact earlier in the file there is another opportunity for the same bug but someone noticed it. The symptom is that packets being sent over UDP sockets, such as used by routed(8), get stamped with the wrong "from" address. This is because in_pcbsetaddr() is calling ifa_ifwithdstaddr() with the socket address it is looking for, instead of a socket address with a zero port number. Ifa_ifwithdstaddr is then comparing the entire 14 bytes of sockaddr data to the data in the ifaddr entry, and of course the sockaddr in the ifaddr entry has a zero port number. So the compare fails. The earlier code I referred to is a similar call to ifa_ifwithaddr(); look for yourself for the fix used. The fix I used is similar; here is the original code: if (ia == 0) { ia = (struct in_ifaddr *) ifa_ifwithdstaddr((struct sockaddr *)sin); if (ia == 0) ia = in_iaonnetof(in_netof(sin->sin_addr)); if (ia == 0) ia = in_ifaddr; if (ia == 0) return (EADDRNOTAVAIL); } and here is my fixed version (I know it isn't pretty, I didn't care about esthetics when I fixed it): if (ia == 0) { int oldport; oldport = sin->sin_port; sin->sin_port = 0; /* for ifa_ifwithdstaddr */ ia = (struct in_ifaddr *) ifa_ifwithdstaddr((struct sockaddr *)sin); if (ia == 0) ia = in_iaonnetof(in_netof(sin->sin_addr)); sin->sin_port = oldport; if (ia == 0) ia = in_ifaddr; if (ia == 0) return (EADDRNOTAVAIL); } der Mouse Smart mailers: mouse@mcgill-vision.uucp USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!musocs!mcgill-vision!mouse think!mosart!mcgill-vision!mouse ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [898@saturn.ucsc.edu] <1987092619225700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: eshop@saturn.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: DSU/CSU units Message-ID: <898@saturn.ucsc.edu> Date: Sat, 26-Sep-87 23:22:57 EDT Article-I.D.: saturn.898 Posted: Sat Sep 26 23:22:57 1987 Date-Received: Tue, 29-Sep-87 02:49:14 EDT References: <8709240904.AA11398@ucbvax.Berkeley.EDU> Reply-To: eshop@saturn.ucsc.edu (Jim Warner) Distribution: world Organization: University of California, Santa Cruz; CIS/CE Lines: 16 Keywords: csu T1 After I wrote about my Verilink experiences, the machine room at the far end of our T1 line had an air conditioning failure. By the time the temperature had reached 85 F, our packet loss rate had climbed to something on the order of 70 percent. The guy at the other end of the wire opened the doors to the machine room (it was evening and fairly cool outside) and pulled the temperature down. The packet losses dropped back down to near zero. There are three Verilinks in the same cabinet in the aforementioned room (this is at Stanford). Only our line suffered when the temp climbed. My conclusion is that there is definitely something wrong with that Verilink. NOTHING should be that temperature sensitive, as the other two Verilinks in the cabinet testify. The environmental spec's for the 551VCC/U call for it to operate at up to 50 C (122 F) so it's clear we have a lemon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709270622.AA01122@sluggo.sun.com] <1987092622223600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: melohn@SUN.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP and DECnet Message-ID: <8709270622.AA01122@sluggo.sun.com> Date: Sun, 27-Sep-87 02:22:36 EDT Article-I.D.: sluggo.8709270622.AA01122 Posted: Sun Sep 27 02:22:36 1987 Date-Received: Sun, 27-Sep-87 21:38:16 EDT References: <159@medivax.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: melohn@Sun.COM (Bill Melohn) Distribution: world Organization: Sun Microsystems, Mountain View Lines: 4 Technically speaking, DECservers do not speak DECnet, they use a DEC propriatary protocol called LAT. This is an ethernet protocol which coexists with any other Ethernet protocol (like TCP/IP) without any problems. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1600@ukecc.engr.uky.edu] <1987092708564700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: edward@engr.uky.edu (Edward C. Bennett) Newsgroups: comp.protocols.tcp-ip Subject: Re: Public Domain TCP/IP Message-ID: <1600@ukecc.engr.uky.edu> Date: Sun, 27-Sep-87 12:56:47 EDT Article-I.D.: ukecc.1600 Posted: Sun Sep 27 12:56:47 1987 Date-Received: Mon, 28-Sep-87 02:50:15 EDT References: <358@palladium.UUCP> <28325@sun.uucp> Reply-To: edward@engr.uky.edu (Edward C. Bennett) Followup-To: comp.sources.wanted Organization: Univ. of KY Engineering Computing Center Lines: 12 In article <28325@sun.uucp> jlp@sun.UUCP (John Pope) writes: >In article <358@palladium.UUCP> gkenley@palladium.UUCP (Greg Kenley) writes: >>"Home of the DataTub" > What's a DataTub?? Perhaps a large bit-bucket? -- Edward C. Bennett DOMAIN: edward@engr.uky.edu UUCP: cbosgd!ukma!ukecc!edward "Goodnight M.A." BITNET: edward%ukecc.uucp@ukma "He's become a growling, snarling white-hot mass of canine terror" ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709271744.AA17924@ucbvax.Berkeley.EDU] <1987092709312200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: blumenth@VAX.BBN.COM (Steve Blumenthal) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP for HP 3000s? Message-ID: <8709271744.AA17924@ucbvax.Berkeley.EDU> Date: Sun, 27-Sep-87 13:31:22 EDT Article-I.D.: ucbvax.8709271744.AA17924 Posted: Sun Sep 27 13:31:22 1987 Date-Received: Mon, 28-Sep-87 02:08:40 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 36 James, Here is a message which I sent to the TCP/IP mailing list back in April about the BBN developed TCP/IP software for the HP3000. /Steve -------------------------------------------------------------------------- Received: from sri-nic.arpa by VAX.BBN.COM id a004313; 15 Apr 87 0:15 EST Received: from VAX.BBN.COM by SRI-NIC.ARPA with TCP; Tue 14 Apr 87 11:56:00-PDT Date: Tue, 14 Apr 87 13:48:20 EST From: Steve Blumenthal To: tcp-ip@sri-nic.ARPA Subject: Re: TCP on an HP 3000 BBN had a contract from DARPA to develop TCP/IP for the HP3000. Under that effort we also developed user and server TELNET and user FTP. This software required modifications to the HP3000 operating system and ran on an HP3000 Series 3 under MPE IV. We completed this effort in 1983 and delivered the software to White Sands Missle Range, where it was modified to run on an HP3000 Series 44 system under the MPE V/P operating system. Because we needed access to the HP3000 operating system sources, we had to sign a source license with HP. This agreement restricts our ability to redistribute this software except to U.S. government sites as directed by DARPA. Because BBN is not heavily involved with the development of software for the HP3000, we tried to give our software to HP to have them support it and track subsequent HP3000 operating system and hardware improvements. To date, HP has not taken us up on our offer. They may be in the process of developing TCP/IP for the HP3000 themselves, but at this point, we have no current contacts at HP. Steve Blumenthal BBN Laboratories ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092709312201> Received: from VAX.BBN.COM by SRI-NIC.ARPA with TCP; Sun 27 Sep 87 10:39:42-PDT Date: Sun, 27 Sep 87 13:31:22 EDT From: Steve Blumenthal To: James Van Bokkelen cc: tcp-ip@SRI-NIC.ARPA Subject: Re: TCP/IP for HP 3000s? James, Here is a message which I sent to the TCP/IP mailing list back in April about the BBN developed TCP/IP software for the HP3000. /Steve -------------------------------------------------------------------------- Received: from sri-nic.arpa by VAX.BBN.COM id a004313; 15 Apr 87 0:15 EST Received: from VAX.BBN.COM by SRI-NIC.ARPA with TCP; Tue 14 Apr 87 11:56:00-PDT Date: Tue, 14 Apr 87 13:48:20 EST From: Steve Blumenthal To: tcp-ip@sri-nic.ARPA Subject: Re: TCP on an HP 3000 BBN had a contract from DARPA to develop TCP/IP for the HP3000. Under that effort we also developed user and server TELNET and user FTP. This software required modifications to the HP3000 operating system and ran on an HP3000 Series 3 under MPE IV. We completed this effort in 1983 and delivered the software to White Sands Missle Range, where it was modified to run on an HP3000 Series 44 system under the MPE V/P operating system. Because we needed access to the HP3000 operating system sources, we had to sign a source license with HP. This agreement restricts our ability to redistribute this software except to U.S. government sites as directed by DARPA. Because BBN is not heavily involved with the development of software for the HP3000, we tried to give our software to HP to have them support it and track subsequent HP3000 operating system and hardware improvements. To date, HP has not taken us up on our offer. They may be in the process of developing TCP/IP for the HP3000 themselves, but at this point, we have no current contacts at HP. Steve Blumenthal BBN Laboratories ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12338118384.21.DOLSON@ADA20.ISI.EDU] <1987092720283000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dolson@ADA20.ISI.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP and DECnet Message-ID: <12338118384.21.DOLSON@ADA20.ISI.EDU> Date: Mon, 28-Sep-87 00:28:30 EDT Article-I.D.: ADA20.12338118384.21.DOLSON Posted: Mon Sep 28 00:28:30 1987 Date-Received: Tue, 29-Sep-87 01:39:48 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 > From: melohn@Sun.COM (Bill Melohn) > Technically speaking, DECservers do not speak DECnet, they use a DEC > propriatary protocol called LAT. This is an ethernet protocol which > coexists with any other Ethernet protocol (like TCP/IP) without any > problems. Mostly right, thats during normal operations. However, during software downline loading from a VAX or PDP (or other?) host, and during the infrequent software crash dump UPline load, they do speak DECnet. Also, they support remote console facility which I guess is also DECnet...(thats NCP> CONNECT CONSOLE, check it out, nice for the times when you have to forceably logout a locked-up port and the terminal server in question is a long stroll away down the building!) Point is, 'technically speaking' the beasties do speak both LAT and DECnet, sometimes at the same time. Doug ------- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709281241.AA04869@mitre.arpa] <1987092804414300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA (H. Craig McKee) Newsgroups: comp.protocols.tcp-ip Subject: Re: DSU/CSU units Message-ID: <8709281241.AA04869@mitre.arpa> Date: Mon, 28-Sep-87 08:41:43 EDT Article-I.D.: mitre.8709281241.AA04869 Posted: Mon Sep 28 08:41:43 1987 Date-Received: Tue, 29-Sep-87 04:27:06 EDT References: <898@saturn.ucsc.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The MITRE Corp., Washington, D.C. Lines: 6 At the risk of discussing the obvious: You noted that one of three Verilinks behaved badly when the temperature went up. It may be that the distribution of cooling air within the cabinet was such that yours went out-of-spec. Regards - Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870928095131.6.DCP@KOYAANISQATSI.S4CC.Symbolics.COM] <1987092805510000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: RCTE Message-ID: <870928095131.6.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Mon, 28-Sep-87 09:51:00 EDT Article-I.D.: KOYAANIS.870928095131.6.DCP Posted: Mon Sep 28 09:51:00 1987 Date-Received: Tue, 29-Sep-87 04:43:09 EDT References: <8709261909.AA10409@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 13 RCTE sounds a lot like the echo-negotiation protocol that the Multics Emacs people developed circa 1980. I'm sorry I can't give you a reference; they may not have published anything. There is and has been a display oriented terminal protocol for a long, long time. The only reason it needs "dusting off" is because only now are commonplace terminals and computer systems really able to take advantage of it. Most operating systems were (originally) written with printing terminals in mind, which is why it has been hard to graft this into existing systems, such as TOPS20. I'm refering, of course, to the SUPDUP protocol, RFC 734 of 1978. If you want graphics, you can do that too: the SUPDUP Graphics extension, RFC 746 March 1978. I suggest you look at these before doing too much wheel reinvention. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709281505.AA02244@ucbvax.Berkeley.EDU] <1987092806532900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) Newsgroups: comp.protocols.tcp-ip Subject: Re: RCTE Message-ID: <8709281505.AA02244@ucbvax.Berkeley.EDU> Date: Mon, 28-Sep-87 10:53:29 EDT Article-I.D.: ucbvax.8709281505.AA02244 Posted: Mon Sep 28 10:53:29 1987 Date-Received: Tue, 29-Sep-87 05:43:05 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 22 Dave-- It happens that I had occasion to check with John Day about his "NVDET" (Network Virtual Data Entry Terminal) stuff several years ago. He told me to wait for the ISO Virtual Terminal Protocol instead. So I did that. And did that. And am still doing that. Actually, some work on NVDET is/was being done in the "DoDIIS" (DoD Intelligence Information System) arena. A year or so ago, I reviewed a draft RFC on the topic by a contractor; still waiting for the next draft. Since it was intended for release to the research community eventually, you might see it before I do if impending threats to my daily access to the net eventuate. In my view, the trouble with NVDET--and TN3270, which somebody semi-facetiously put forward in a side msg--is that you get wrapped around the the screen-at-a-time axle instead of the char-a-a-t one, and in the context we're addressing that isn't desirable. (Not to deny that there are contexts in which it's necessary to deal with screen-a-a-t, just to observe that this doesn't have to be one of them--unless, of course, a solution to char-a-a-t falls out of it naturally.) Are you volunteering to retrieve the RCTE baton/torch, by the way? cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092806532901> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Mon 28 Sep 87 07:57:29-PDT Date: 28 Sep 1987 10:53:29 EDT Subject: Re: RCTE From: Michael Padlipsky To: "Dave Crocker" cc: "tcp-ip" In-Reply-To: (Message from ""Dave Crocker" " of 25 Sep 87 17:36:00 PDT) Dave-- It happens that I had occasion to check with John Day about his "NVDET" (Network Virtual Data Entry Terminal) stuff several years ago. He told me to wait for the ISO Virtual Terminal Protocol instead. So I did that. And did that. And am still doing that. Actually, some work on NVDET is/was being done in the "DoDIIS" (DoD Intelligence Information System) arena. A year or so ago, I reviewed a draft RFC on the topic by a contractor; still waiting for the next draft. Since it was intended for release to the research community eventually, you might see it before I do if impending threats to my daily access to the net eventuate. In my view, the trouble with NVDET--and TN3270, which somebody semi-facetiously put forward in a side msg--is that you get wrapped around the the screen-at-a-time axle instead of the char-a-a-t one, and in the context we're addressing that isn't desirable. (Not to deny that there are contexts in which it's necessary to deal with screen-a-a-t, just to observe that this doesn't have to be one of them--unless, of course, a solution to char-a-a-t falls out of it naturally.) Are you volunteering to retrieve the RCTE baton/torch, by the way? cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092808010200> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Mon 28 Sep 87 10:56:56-PDT Received: from SUVM.BITNET by wiscvm.wisc.edu ; Mon, 28 Sep 87 12:33:12 CDT Received: by SUVM (Mailer X1.25) id 8191; Mon, 28 Sep 87 13:31:13 LCL Date: Mon, 28 Sep 1987 13:01:02 LCL From: John M. Wobus To: TCP-IP Discussion Group Subject: RTCE & Line-at-a-time TELNET-like protocols DEC's TOPS-10 OS optionally echos for user programs and does it remotely via its "ANF-10" networking protocols. It allows a user program to declare its own set of input characters that stop echoing. It goes to a lot of trouble to make certain that the first characters that are not supposed to echo, don't (like passwords). I recall some technical device they call "pipeline echo markers". My own inclination is that any protocol adopted in this day and age should be able to locally generate cursor movements in response to cursor movement keys. John Wobus Syracuse University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12338250870.20.PERILLO@SRI-NIC.ARPA] <1987092808361600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERILLO@SRI-NIC.ARPA (Francine Perillo) Newsgroups: comp.protocols.tcp-ip Subject: DDN "Vendors Guide" Message-ID: <12338250870.20.PERILLO@SRI-NIC.ARPA> Date: Mon, 28-Sep-87 12:36:16 EDT Article-I.D.: SRI-NIC.12338250870.20.PERILLO Posted: Mon Sep 28 12:36:16 1987 Date-Received: Tue, 29-Sep-87 06:14:52 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 18 Having noticed recent inquiries on this mailing list for a list of TCP/IP implementations, it seems appropriate to announce that a new version of the "DDN Protocol Implementations and Vendors Guide" is available from the NIC. This document is issued by SRI under contract with DCA. The online file is FTP'able from SRI-NIC.ARPA using the anonymous login convention: log in as "anonymous", with password of "guest". Pathname is NETINFO:VENDORS-GUIDE.DOC A hardcopy version (dated August 1987) is also available. Contact NIC@SRI-NIC.ARPA for details on how to order this. Request to all: Kindly let us know about implementations which are missing from this document. -Francine /NIC ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3910006@hpindda.HP.COM] <1987092809505300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kumar@hpindda.HP.COM (Krishna Kumar) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP for HP 3000s? Message-ID: <3910006@hpindda.HP.COM> Date: Mon, 28-Sep-87 13:50:53 EDT Article-I.D.: hpindda.3910006 Posted: Mon Sep 28 13:50:53 1987 Date-Received: Thu, 1-Oct-87 04:04:26 EDT References: <8709260145.AA22824@spdcc.COM> Organization: Hewlett Packard, Cupertino Lines: 95 / hpindda:comp.protocols.tcp-ip / jbvb@ftp.UUCP (James Van Bokkelen) / 6:04 pm Sep 25, 1987 / I'm pretty sure HP doesn't have one. Does anything exist in the public domain, or from another vendor? If respondents think there will be enough responses to annoy the list, send them to me, and I will summarize. spdcc!ftp!jbvb@harvard.harvard.edu James B. VanBokkelen FTP Software Inc. 501 Cambridge St. Cambridge, MA 02141 (617) 868-4878 ---------- DISCLAIMER: This is a statement based on my personal knowledge, to give you an idea of the TCP/IP products on the HP3000s and is NOT to be taken as an official statement of the Hewlett-Packard Company. I have been maintaining the TCP/IP product on the HP3000 for the last year and a half, so I would state with reasonable surety that HP does have a TCP/IP product for its 3000 family of computers!!! The first release of TCP/IP for the 3000 which is part of the Network Transport (NXPORT) product was in March '85. The transport supports HP's proprietary Networking Services (NS/3000). Note that the two are separate products and can be bought independently. The NXPORT product if bought by itself could still be used for the NetIPC (Inter Process Communication) interface that it provides. The Services would not be of any use if bought without NXPORT. This initial phase I release, was a IEEE 802.3 LAN only product. The second release of Transport for the HP3000 (Netxport II) came out in March '87 and is the phase II version of the Transport. This comprises of various functional enhancements to the Transport including support of point-to-point links, Transport level DDN compatibility and Transparent nodal access (store and forward) for both intranet and internet destinations (includes gateways and gateway halves). Netxport II is backward compatible with the phase I product. The following excerpts taken from the "NS3000/V Network Manager Reference Manual, Volume I", gives an idea of the capabilities of the networking products on the 3000s. "NS3000/V consists of two parts: NS3000/V Services and NS3000/V links. Network Services consist of software that enables users to access data, initiate processes, and exchange information among all systems on a network. NS3000/V links provide connections among systems (either HP3000s or personal computers) in the same network. To use NS3000/V Services, the systems must be connected by an NS3000/V network link. A variety of network link products are available with NS3000/V. The link product that connects individual systems in an NS3000/V network can be any of the following: o NS Point-to-Point Network Link for MPE-V based systems o Asynchronous SERIAL Network Link o StarLAN/3000 Link o ThinLAN/3000 Link (includes ThickLAN option for thick coaxial cable..) The link products listed above can all be used to connect HP3000s to one another The Asynchronous SERIAL Network Link, StarLAN/3000, and ThinLAN/3000 can connect HP 3000s to personal computers as well as to other HP3000s. The ThinLAN/3000 Link, including the ThickLAN option, can also connect HP3000s with HP 1000s and HP 9000s." Netxport II is bundled with hardware, NetIPC and driver software to form several network link products. The ARPA services FTP, TELENET and SMTP will be available for the 3000 around April '88. These services are being developed by The Wollongong Group. The X.25 link product for the HP3000 will be available around July '88. To my knowledge the BBN software was not used to develop any product. As the disclaimer states, this statement is my own, written to give you some information about the HP3000 networking products, and I (and NOT the Hewlett Packard Company) am responsible for any oversights/misstatements. Please contact the marketing dept. for official statements and information regarding the 3000 networking products. Best Regards, Krishna Kumar Software Development Engineer MS43 UX Information Networks Division Hewlett Packard 19420 Homestead Road Cupertino, CA 95014. (hpda!hpindda!kumar@hplabs.HP.COM) (408-447-2970) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092810003200> Received: from F4.CSL.SRI.COM by SRI-NIC.ARPA with TCP; Mon 28 Sep 87 17:00:36-PDT Date: Mon 28 Sep 87 17:00:32-PDT From: Karl Auerbach Subject: TCP performance limitations To: tcp-ip@SRI-NIC.ARPA Someone asked me today what are the performance limits on a TCP connection. The situation he posited was on in which there are no intervening IP routers, massive availability of underlying bandwidth, massive computing resources in the hosts, and low noise. It was further posited that the hosts could be using acknowledgement strategies highly tuned for this specific situation. How to make such an estimate is well outside my expertise. Can anyone give me any pointers? Thanks, --karl-- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092810280000> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Mon 28 Sep 87 13:34:17-PDT Received: from UCIVMSA.BITNET by wiscvm.wisc.edu ; Mon, 28 Sep 87 15:33:24 CDT Date: 28 SEP 87 13:28-SYS From: mslagley%UCIVMSA.BITNET@wiscvm.wisc.edu To: TCP-IP@SRI-NIC.ARPA Subject: Re: PC Telnet with Tek Graphics emulator X-Original_To: BEAME%MCMASTER.BITNET%WISCVM.WISC.EDU@orion X-Routing: SMTPUSER @ WISCVM Received: from ORION by UCICP6 with PMDFs; 28 Sep 1987 13:13:08 Received: from localhost by orion.cf.uci.edu id a016378; 28 Sep 87 13:09 PDT In-reply-to: Your message of Sat, 26 Sep 87 10:38:00 -0400.<8709262251.aa10347@I CS.UCI.EDU> Date: Mon, 28 Sep 87 13:09:48 -0700 From: mslagley@orion.cf.uci.edu Beam & Witeside is sending their promotional information. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709282048.AA02307@ucbvax.Berkeley.EDU] <1987092814001700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mslagley@UCIVMSA.BITNET Newsgroups: comp.protocols.tcp-ip Subject: Re: PC Telnet with Tek Graphics emulator Message-ID: <8709282048.AA02307@ucbvax.Berkeley.EDU> Date: Mon, 28-Sep-87 18:00:17 EDT Article-I.D.: ucbvax.8709282048.AA02307 Posted: Mon Sep 28 18:00:17 1987 Date-Received: Tue, 29-Sep-87 07:31:05 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 Received: from ORION by UCICP6 with PMDFs; 28 Sep 1987 13:13:08 Received: from localhost by orion.cf.uci.edu id a016378; 28 Sep 87 13:09 PDT In-reply-to: Your message of Sat, 26 Sep 87 10:38:00 -0400.<8709262251.aa10347@I CS.UCI.EDU> Date: Mon, 28 Sep 87 13:09:48 -0700 From: mslagley@orion.cf.uci.edu Beam & Witeside is sending their promotional information. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709282227.AA00475@jpl-mil.Jpl.Nasa.Gov] <1987092814270800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jaw@JPL-MIL.JPL.NASA.GOV (Joe Wieclawek) Newsgroups: comp.protocols.tcp-ip Subject: tcp-ip mailing list Message-ID: <8709282227.AA00475@jpl-mil.Jpl.Nasa.Gov> Date: Mon, 28-Sep-87 18:27:08 EDT Article-I.D.: jpl-mil.8709282227.AA00475 Posted: Mon Sep 28 18:27:08 1987 Date-Received: Wed, 30-Sep-87 05:55:42 EDT Sender: usenet@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 Sorry to bother the net with this but my requests to TCP-IP-REQUEST seem to fall in the bit bucket. Please change the address on the TCP-IP distribution list from jaw@jpl-vlsi.arpa to tcp-ip@jpl-mil.jpl.nasa.gov OR tcp-ip@jpl-mil.arpa (26.9.0.65) Thanks, Joe Wieclawek Mail stop: 602-145 Jet Propulsion Laboratory Office: (818)354-2419 FTS: 792-2419 4800 Oak Grove Drive jaw@sesun.jpl.nasa.gov Pasadena CA 91109 System Engineering Communications and Computing Network Services Section ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12338315541.10.BILLW@MATHOM.CISCO.COM] <1987092814313100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BILLW@MATHOM.CISCO.COM (William Westfield) Newsgroups: comp.protocols.tcp-ip Subject: SUPDUP protocol Message-ID: <12338315541.10.BILLW@MATHOM.CISCO.COM> Date: Mon, 28-Sep-87 18:31:31 EDT Article-I.D.: MATHOM.12338315541.10.BILLW Posted: Mon Sep 28 18:31:31 1987 Date-Received: Thu, 1-Oct-87 03:58:16 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 37 Although the SUPDUP protocol has a lot of advantages over the TELNET protocol for modern computers systems, it does not provide for any local echoing capability at all, nor does it provide for local "break characters" (what it does provide is a standard way of negotiating terminal capabilities (now somewhat dated in scope), and terminal independent display capabilities). TOPS20 has the concept of a break character bitmap, but not for an echoing bitmap, and it required monitor modifications to get the break character implementation to be at all useful to the popular display editor emacs. (I originally implemented these changes back at SRI, to (hopefully) lessen the impact of emacs on system performance. I believe that VMS has a similar scheme. DEC's CTERM protocol provides the means of transmitting such info over a network connection, but DEC engineers I have talked with said that even within DEC, the standard is rather abused (eg, most of VMS terminal IO is done via system-extension-code XYZZY, and such). Unix, one of the worlds most popular operating systems, doesn't have either concept. The Annex boxes implement some local editing functionality, but this requires both a custom version of the editor, and custom software on the Annex, and is not a published standard. (nor does it help outside of the editor...) A good protocol would permit some local intelligence (eg echoing, bunching of characters) without the local server having to know specifics about the type of terminal being used. What it amounts to is that most operating systems are STILL dealing with the terminal as if it were a printer, and that this probably has to change before a smarter virtual terminal protocol can be defined. Bill Westfield cisco Systems ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709290008.AA00477@ucbvax.Berkeley.EDU] <1987092816003200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: AUERBACH@CSL.SRI.COM (Karl Auerbach) Newsgroups: comp.protocols.tcp-ip Subject: TCP performance limitations Message-ID: <8709290008.AA00477@ucbvax.Berkeley.EDU> Date: Mon, 28-Sep-87 20:00:32 EDT Article-I.D.: ucbvax.8709290008.AA00477 Posted: Mon Sep 28 20:00:32 1987 Date-Received: Wed, 30-Sep-87 05:48:40 EDT Sender: usenet@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Someone asked me today what are the performance limits on a TCP connection. The situation he posited was on in which there are no intervening IP routers, massive availability of underlying bandwidth, massive computing resources in the hosts, and low noise. It was further posited that the hosts could be using acknowledgement strategies highly tuned for this specific situation. How to make such an estimate is well outside my expertise. Can anyone give me any pointers? Thanks, --karl-- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709290201.aa23234@Huey.UDEL.EDU] <1987092822011300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP performance limitations Message-ID: <8709290201.aa23234@Huey.UDEL.EDU> Date: Tue, 29-Sep-87 02:01:13 EDT Article-I.D.: Huey.8709290201.aa23234 Posted: Tue Sep 29 02:01:13 1987 Date-Received: Wed, 30-Sep-87 06:13:23 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Karl, Geez, how can I respond to such a wonder? Given your scenario, I would posit something like X-band speeds, which works out to 10^10 bps, assuming you use the right waveguide. Now, if you are phond of photons, we can escalate that a few megatons. Seriously, existing Unix implementations might horse up to a couple of megabits, but Craymonsters on Hyperbolts might up that a magnitude. Meanwhile, ask Dave Clark at MIT about the NETBLT performance, which is currently dimming the lights on FATNET at megabit speeds over real satellite channels. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709290741.AA02129@sluggo.sun.com] <1987092823410400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: melohn@SUN.COM (Bill Melohn) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP and DECnet Message-ID: <8709290741.AA02129@sluggo.sun.com> Date: Tue, 29-Sep-87 03:41:04 EDT Article-I.D.: sluggo.8709290741.AA02129 Posted: Tue Sep 29 03:41:04 1987 Date-Received: Wed, 30-Sep-87 06:38:09 EDT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Not true. Downline loading, upline dumping, and the remote console utility are handled by MOP, the Maintenance Operations Protocol, yet another Digital propriatary protocol that is NOT included under the publically available DECnet suite. True, to provide a mapping between LAT server names and their ethernet addresses they use the DECnet node database, but this is purely an implementation convienence (since their is no DNA equivalant of ARP). The point I was making is that DECnet is a publically specified interface for talking to DEC machines; however it does NOT include terminal servers, VAX clusters, and many other protocols which Digital considers propritary. I'm tired of explaining to customers why we can't support DEC terminal servers, "since they run DECnet" (which we can and do support under SunOS). ----MESSAGE-END---- ----MESSAGE-BEGIN---- [181@wright.EDU] <1987092903221300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jsloan@wright.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP and DECnet Message-ID: <181@wright.EDU> Date: Tue, 29-Sep-87 07:22:13 EDT Article-I.D.: wright.181 Posted: Tue Sep 29 07:22:13 1987 Date-Received: Thu, 1-Oct-87 02:11:43 EDT References: <8709270622.AA01122@sluggo.sun.com> Distribution: world Organization: Wright State University, Dayton OH, 45435 Lines: 31 in article <8709270622.AA01122@sluggo.sun.com>, melohn@SUN.COM (Bill Melohn) says: > > Technically speaking, DECservers do not speak DECnet, they use a DEC > propriatary protocol called LAT. This is an ethernet protocol which > coexists with any other Ethernet protocol (like TCP/IP) without any > problems. True, LAT terminal servers are nice with LAT-capable machines (like VMS or Ultrix) but just about useless with any other vendors equipment, which is why we're going to TCP/IP terminal servers. Anyway, I think the issue here is whether the TCP/IP code and the DECnet code running on the same machine can coexist on the same ethernet controller, which is a very sticky question. The DECnet/Ultrix implementations seems to work fine. We use DECnet to talk to the VMS machines, TCP/IP (and NFS) to talk to the UNIX machines and our terminal servers, and LAT to talk to the few LAT boxes in other departments. I remember reading, I think, that other commercial products, like TWG's TCP/IP for VMS, would do the same. But I would read the fine print very carefully. I do know that there were a variety of changes to the networking code in Ultrix to support DECnet. I seem to recall that the lowest level TCP/IP layer was boosted up above an sort of generic ethernet packet server that controlled the interface board, and handed out appropriate ethernet packets to the TCP/IP or DECnet code. -- John Sloan CSNET: jsloan@CS.Wright.EDU UUCP: ...!cbosgd!wright!jsloan Computer Science Department, Wright State University, Dayton OH, 45435 +1 513 873 2491 belong(opinions,jsloan). belong(opinions,_):-!,fail. The only thing that depreciates faster than a computer is fresh fruit. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709291210.AA02469@work1.icase] <1987092904105000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: doug@ICASE.ARPA (Doug Peterson) Newsgroups: comp.protocols.tcp-ip Subject: in.routed dying Message-ID: <8709291210.AA02469@work1.icase> Date: Tue, 29-Sep-87 08:10:50 EDT Article-I.D.: work1.8709291210.AA02469 Posted: Tue Sep 29 08:10:50 1987 Date-Received: Wed, 30-Sep-87 07:13:17 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 34 I'm experiencing a phenomenon with my routed daemon. It dies at seemingly random intervals, for no apparent reason. My configuration is as follows: -------------------------------------------------------------- | | | 128.102.7.51 (outside world) ---- ------- | |P4200 gw | | Sun 3/180 file server (runs in.routed) ---- -------- | |192.12.48.1 ------------------- ---------------------------- (private net) Another net | | | | |192.48.12.n --- --- --- --- --- | | | | | | | | | | --- --- --- --- --- 14 3/50 diskless clients I'm running Sun OS 3.4 currently, but I've had the same problem under 3.3. The file server has 8mb ram, 2 380mb Eagle disks, an FPA card, 16 serial lines for printers, terminals, etc. Admittedly, the system is loaded, but other things function properly, with response we can live with. However, routed just dies without a clue. Sun says they haven't heard of this problem with other customers. Does anyone have any ideas about what to look at, or has anyone experienced a similar problem? Thanks. Doug Peterson Systems Manager (804) 865-4090 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709291301.AA12666@saturn.mitre.org] <1987092905011500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lazear@GATEWAY.MITRE.ORG Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP performance limitations Message-ID: <8709291301.AA12666@saturn.mitre.org> Date: Tue, 29-Sep-87 09:01:15 EDT Article-I.D.: saturn.8709291301.AA12666 Posted: Tue Sep 29 09:01:15 1987 Date-Received: Wed, 30-Sep-87 07:13:40 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Karl, It sounds like you've removed the major bottlenecks and throughput ought to approach infinity! :-) Without queue delays, transmission delays, checksum computing delays, and retransmissions, there's not much left to stall data. Walt ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870929090456.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM] <1987092905040000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) Newsgroups: comp.protocols.tcp-ip Subject: TCP performance limitations Message-ID: <870929090456.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Tue, 29-Sep-87 09:04:00 EDT Article-I.D.: KOYAANIS.870929090456.5.DCP Posted: Tue Sep 29 09:04:00 1987 Date-Received: Wed, 30-Sep-87 07:13:51 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Given your assumptions, TCP is not the limitting factor. The limitting factor are rate at which producers can produce data and consumers can consume it. It is quite easy to multibuffer TCP, and I suspect most implementations have. Given the horsepower of the consumer and the producer, and the channel bandwidth, and the multibuffering methodology, you can probably calculate the minimum window size that ensures the pipe will always be full. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709291407.AA17543@ucbvax.Berkeley.EDU] <1987092906092900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JMWOBUS@SUVM.BITNET (John M. Wobus) Newsgroups: comp.protocols.tcp-ip Subject: RTCE & Line-at-a-time TELNET-like protocols Message-ID: <8709291407.AA17543@ucbvax.Berkeley.EDU> Date: Tue, 29-Sep-87 10:09:29 EDT Article-I.D.: ucbvax.8709291407.AA17543 Posted: Tue Sep 29 10:09:29 1987 Date-Received: Wed, 30-Sep-87 07:15:20 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 13 DEC's TOPS-10 OS optionally echos for user programs and does it remotely via its "ANF-10" networking protocols. It allows a user program to declare its own set of input characters that stop echoing. It goes to a lot of trouble to make certain that the first characters that are not supposed to echo, don't (like passwords). I recall some technical device they call "pipeline echo markers". My own inclination is that any protocol adopted in this day and age should be able to locally generate cursor movements in response to cursor movement keys. John Wobus Syracuse University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709291511.AA18314@ucbvax.Berkeley.EDU] <1987092906553800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) Newsgroups: comp.protocols.tcp-ip Subject: Re: RCTE Message-ID: <8709291511.AA18314@ucbvax.Berkeley.EDU> Date: Tue, 29-Sep-87 10:55:38 EDT Article-I.D.: ucbvax.8709291511.AA18314 Posted: Tue Sep 29 10:55:38 1987 Date-Received: Wed, 30-Sep-87 07:18:55 EDT References: <870928095131.6.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 13 Never having been at all fond of reinventing wheels, I hastened to FTP the SUPDUP RFC and print it out at my terminal. When I got to "Due to the highly interactive characteristics of both the SUPDUP protocol and the ITS system [which was the original Server for which the protocol was developed], all transactions are strictly character at a time and all echoing is remote" I aborted the printing. Am I misunderstanding something--the context is, as far as I know, avoiding "unnecessary" transmissions--or have you misremembered SUPDUP? (If the latter, let me be the first to welcome you to Early Middle Age.) As things stand, I have to deem SUPDUP a reinvention of the travois, in context; please correct me if I'm wrong. cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092906553801> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 29 Sep 87 08:02:33-PDT Date: 29 Sep 1987 10:55:38 EDT Subject: Re: RCTE From: Michael Padlipsky To: David C. Plummer cc: Dave Crocker , Charles Hedrick , BEAME%MCMASTER.BITNET@WISCVM.WISC.EDU, "GBURG::ENGER" , tcp-ip , enger@SCRC-QUABBIN.ARPA In-Reply-To: <870928095131.6.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Never having been at all fond of reinventing wheels, I hastened to FTP the SUPDUP RFC and print it out at my terminal. When I got to "Due to the highly interactive characteristics of both the SUPDUP protocol and the ITS system [which was the original Server for which the protocol was developed], all transactions are strictly character at a time and all echoing is remote" I aborted the printing. Am I misunderstanding something--the context is, as far as I know, avoiding "unnecessary" transmissions--or have you misremembered SUPDUP? (If the latter, let me be the first to welcome you to Early Middle Age.) As things stand, I have to deem SUPDUP a reinvention of the travois, in context; please correct me if I'm wrong. cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709291523.AA18498@ucbvax.Berkeley.EDU] <1987092907072700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: vwhite@NSWC-G.ARPA Newsgroups: comp.protocols.tcp-ip Subject: more on LONEX? Message-ID: <8709291523.AA18498@ucbvax.Berkeley.EDU> Date: Tue, 29-Sep-87 11:07:27 EDT Article-I.D.: ucbvax.8709291523.AA18498 Posted: Tue Sep 29 11:07:27 1987 Date-Received: Wed, 30-Sep-87 07:19:07 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 45 29 September 1987 Merton, Dennis, Steven: Thank you for responses about the LONEX system. We have some questions: It sounds as if the primary function of LONEX is keeping most of the processing on a larger system, away from the PCs, but is doing load balancing to share the work among several such larger systems. Are we on the right track? How about the supported spreadsheet and database programs; are they implemented on the server or the PCs? Where is the mail delivered? Do users have mailboxes on the server? (It doesn't sound like mail is delivered directly to the PC.) Can users send mail from the PC or must they do so directly from the server? How about printing? Must the user queue print jobs from the server or can he do so from the PC? Why are these terminals and PCs connected to your larger systems via an ethernet? Most of the implementations we've seen in which PCs accessed servers only as terminal emulators use asynchronous connections; it's cheaper and can handle the requirement. Is LONEX offering a service that makes the ethernet important? (perhaps those database programs are distributed database servers?) You said LONEX runs on 2.9bsd or 4.3. Did you mean, in addition, anything in the middle? How about vendor implementations of 4.2 such as those of Pyramid or CCI? What software is required on the PC? Do any of the other packages you mentioned (RAPIDE, UTAIN/MAIS, or ULANA) implement a file server? If you could describe them briefly we might know whether it was worthwhile to go looking for more information. Thanks for the help! We want to learn as much as we can from other people before we make any decisions. Vicky White Code K33 NSWC Dahlgren, VA 22448 (703) 663-7745 vwhite@nswc-g.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092907160500> Received: from braden.isi.edu by SRI-NIC.ARPA with TCP; Tue 29 Sep 87 14:42:19-PDT Date: Tue, 29 Sep 87 14:16:05 PDT From: braden@braden.isi.edu Posted-Date: Tue, 29 Sep 87 14:16:05 PDT Message-Id: <8709292116.AA01693@braden.isi.edu> Received: by braden.isi.edu (5.54/5.51) id AA01693; Tue, 29 Sep 87 14:16:05 PDT To: AUERBACH@csl.sri.com, lazear@gateway.mitre.org, tcp-ip@sri-nic.arpa Subject: Re: TCP performance limitations Karl, It sounds like you've removed the major bottlenecks and throughput ought to approach infinity! :-) Without queue delays, transmission delays, checksum computing delays, and retransmissions, there's not much left to stall data. Walt ____________________________ The max TCP window size (2**16) divided by the round-trip delay. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709291530.AA13517@aplpy.ARPA] <1987092907305000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sfp@APLPY.ARPA (Steven Parr) Newsgroups: comp.protocols.tcp-ip Subject: closing half-open connections Message-ID: <8709291530.AA13517@aplpy.ARPA> Date: Tue, 29-Sep-87 11:30:50 EDT Article-I.D.: aplpy.8709291530.AA13517 Posted: Tue Sep 29 11:30:50 1987 Date-Received: Wed, 30-Sep-87 07:19:19 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 24 Hi, We are having problems with tcp connections getting hung in the LAST_ACK state. I believe the fault lies with the software at the other end of the connection and so we are in the process of getting an update of that software. However purchasing takes time and in the mean time, we keep re-transmitting a FIN every second or two until the next reboot. So my question is this: Does anyone know of a way to force closed a half-open connection such as this? Seems to me that you should be able to change the state to FIN_ACK_2 or TIME_WAIT and the connection should go ahead and close itself on the next expiration of the timer. Has anyone tried anything like this? Any suggestions on how to go about it? (Looks like adb may be useful, but I know almost nothing about it.) If it matters, we have a Pyramid running release 3.1 (without source). Thanks in advance, -Steve Parr sfp@aplpy.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709291607.AA11927@uf.msc.umn.edu] <1987092908072600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: slevy@UF.MSC.UMN.EDU (Stuart Levy) Newsgroups: comp.protocols.tcp-ip Subject: Re: RCTE Message-ID: <8709291607.AA11927@uf.msc.umn.edu> Date: Tue, 29-Sep-87 12:07:26 EDT Article-I.D.: uf.8709291607.AA11927 Posted: Tue Sep 29 12:07:26 1987 Date-Received: Thu, 1-Oct-87 04:14:29 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 15 I've just submitted an RFC that tries to deal with this problem -- it basically is CCITT's X.3 adapted for Telnet, with extensions. So it does things like local editing, echoing, selective forwarding, flow control &c, all controllable from the host side. It -doesn't- try to do as much as RCTE. It also doesn't try to provide for general local screen editing, e.g. interpreting & buffering cursor movements -- that seems like an awful lot to pile onto a poor Telnet protocol. I'm leaving the draft RFC for anonymous FTP from uc.msc.umn.edu, as "staff/rfc.x3", if anyone's interested. Stuart Levy Minn. Supercomputer Center 612 626 0211 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092908150000> Received: from acc.arpa by SRI-NIC.ARPA with TCP; Tue 29 Sep 87 16:14:45-PDT Date: 29 Sep 87 16:15:00 PST From: Subject: TCP performance To: "tcp-ip" Reply-To: Hey Folks, Physics won't let us go infinitely fast!!! A practical limit is probably related to distance. Lets look at the facts: TCP has a maximum window size of 65535 bytes (16 bit field). Single satellite hop is approx. 1/2 sec round trip (approx. 90 Thousand miles). Thus for satellite, max. rate is about (65535*8)/(0.5) or 1.048 Megbit/sec. Coast to Coast should be about 30 times quicker, or about 30 Megbit/sec. Of course, this is for a single TCP session, multiply for number of concurrent sessions. Art Berggreen art@acc.arpa ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [559937528.0.CASNER@VENERA.ISI.EDU] <1987092910120800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CASNER@VENERA.ISI.EDU (Stephen Casner) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP performance limitations Message-ID: <559937528.0.CASNER@VENERA.ISI.EDU> Date: Tue, 29-Sep-87 14:12:08 EDT Article-I.D.: VENERA.559937528.0.CASNER Posted: Tue Sep 29 14:12:08 1987 Date-Received: Thu, 1-Oct-87 04:27:47 EDT References: <8709290454.AA24282@venera.isi.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 25 Karl, For all the variables you mention, you've specified values that would pose no limit to TCP performance. However, you left out one critical variable: delay. If the bandwidth and processing power are infinite, the sender will immediately transmit as many octets as the receiver's window will allow. The sender cannot transmit any more until an ACK is returned, and the receiver cannot send an ACK until the data gets there. Therefore, the maximum throughput is one window's worth of octets every round-trip delay time. The window size is determined by the amount of buffer space available in the receiver. If you assume buffer space is also unlimited, then you bump into the first real limit: the maximum TCP window size is 64K octets because it is carried in a 16-bit field. To cite a real example, the Wideband Satellite Network has a raw data rate of 3Mb/s, but it also has a round-trip delay time of 1.8 seconds. The maximum TCP throughput is 64K octets per 1.8 seconds or 290Kb/s. There have been proposals by the INENG Task Force and others to define a TCP option to carry a larger window-size field. If you assume this option field could be as large as necessary, then the only limits left are physical: the speed of light and the distance between hosts. -- Ste. A with t time r ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709291844.AA01684@armagnac.DEC.COM] <1987092911244100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kent@DECWRL.DEC.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP performance limitations Message-ID: <8709291844.AA01684@armagnac.DEC.COM> Date: Tue, 29-Sep-87 15:24:41 EDT Article-I.D.: armagnac.8709291844.AA01684 Posted: Tue Sep 29 15:24:41 1987 Date-Received: Thu, 1-Oct-87 04:31:49 EDT References: <8709291301.AA12666@saturn.mitre.org> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "Christopher A. Kent" Distribution: world Organization: The ARPA Internet Lines: 4 There are some protocol details (like the IP identification field) and common MTUs that will limit the data rate. chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870929154835.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM] <1987092911480000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) Newsgroups: comp.protocols.tcp-ip Subject: Re: RCTE Message-ID: <870929154835.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Tue, 29-Sep-87 15:48:00 EDT Article-I.D.: KOYAANIS.870929154835.2.DCP Posted: Tue Sep 29 15:48:00 1987 Date-Received: Thu, 1-Oct-87 04:35:43 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 I assumed, incorrectly it turns out, that your requests for local echoing and display-oriented terminal service were separate. If your goal is to minimize network traffic, then indeed, SUPDUP is not for you. if your goal is to minimize program (e.g., editor) wakeups, then you can still use SUPDUP as is. You do need to make a system call that causes the system, not the program, to do the echoing and return control to the program on the special characters. ITS has such a system call. Multics has such a system call and/or communication with its front end. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709291436.aa08098@Q2.ICS.UCI.EDU] <1987092914185900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mmolle@Q2.ICS.UCI.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP performance limitations Message-ID: <8709291436.aa08098@Q2.ICS.UCI.EDU> Date: Tue, 29-Sep-87 18:18:59 EDT Article-I.D.: Q2.8709291436.aa08098 Posted: Tue Sep 29 18:18:59 1987 Date-Received: Fri, 2-Oct-87 01:35:42 EDT References: <8709291301.AA12666@saturn.mitre.org> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Hey, wait a minute! Even assuming no errors, arbitrarily high data rates and arbitarily fast processors interpretting the protocols, there is still propagation time across the channel to contend with. Assuming a window size of one (a.k.a. "stop and wait") you get at most one frame per round trip time, i.e., a finite maximum data rate. A larger (but still finite) window size of W outstanding and unacknowledged frames raises that bound by a factor of W, but it certainly doesn't give you infinite throughput. Does that clarify the situation, or am I missing something deeper? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [244@mitisft.Convergent.COM] <1987092914325500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: andrew@mitisft.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: RCTE Message-ID: <244@mitisft.Convergent.COM> Date: Tue, 29-Sep-87 18:32:55 EDT Article-I.D.: mitisft.244 Posted: Tue Sep 29 18:32:55 1987 Date-Received: Fri, 2-Oct-87 00:45:16 EDT References: <8709281505.AA02244@ucbvax.Berkeley.EDU> Distribution: world Organization: Convergent Technologies, San Jose, CA Lines: 20 It seems to me there are is a middle ground in here, between char-at-a-time and line- (or screen-) at-a-time, that can be implemented purely on the server side using the normal telnet protocol (ECHO negotiation). We are considering implementing this for support of low speed TCP links (eg async modems), and I'm curious if I'm going to run into some "common knowledge problem"... The basic idea is to have the kernel (virtual terminal driver) inform the telnet daemon when it *would be* doing immediate character echo, and not do it. The daemon turns this information into echo negotiation, which the client (hopefully) heeds. This results in speeded echo response in (for example) un*x "cooked" mode, plus a reduction in packet traffic. Has anyone tried this? The UCB virtual terminal driver has some hooks in it ("packet mode", currently used for flow control negotiation with rlogin) that could be used for this (after extension). Andrew Knutsen (408)435-3623 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [SRA.12338591874.BABYL@XX.LCS.MIT.EDU] <1987092915490000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: SRA@XX.LCS.MIT.EDU (Rob Austein) Newsgroups: comp.protocols.tcp-ip Subject: RCTE and stranger things Message-ID: Date: Tue, 29-Sep-87 19:49:00 EDT Article-I.D.: XX.SRA.12338591874.BABYL Posted: Tue Sep 29 19:49:00 1987 Date-Received: Sun, 4-Oct-87 19:37:01 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 78 I was going to say something about that, but decided to wait to see if anybody had in fact read Dave's message. You did, so here goes. Yes, SUPDUP as specified in the RFC is character at a time. However, I believe that a very minor enhancement to the protocol would handle that problem. The big advantages of SUPDUP (sales pitch) are that (1) it works in a heterogenous environment (thus is better than rlogin), and (2) has a wider view of the terminal than just the print head of a hardcopy TTY (thus is better than TELNET). In particular, there are a whole set of useful options under the heading of "The Intelligent Terminal Protocol". Not all of these are documented in the SUPDUP RFCs, for a full explanation of the ITS terminal system see the file "MC: INFO; ITSTTY >" on MC.LCS.MIT.EDU. It's a bit long, so if you're not up for a lot of reading, you want the parts on "Control of the TTY" and "The Intelligent Terminal Protocol". The model I'm using for the local/remote echo and wakup problem is the TOPS-20 TEXTI% JSYS, which was mentioned obliquely a few messages ago when somebody referred to TOPS-20 EMACS enhancements. For those who aren't familiar with TOPS-20, one of the arguments to TEXTI% is a break mask, a 128 bit vector indicating which characters should cause the TEXTI% call to return. I believe that the EMACS extentions that were mentioned were based on an extension to TEXTI% which would cause any character with the meta bit (octal 200) turned on to act as a wakeup. I may be wrong about this, I've never seen the code. Presumably the entity that decides what the break mask should be is the server (where applications programs are running) while the entity that implements the break mask is the client (where the physical display terminal is). So presumably the "change the break mask" sequence would begin with a %TDxxx code. I can't think of any reason why the client would want to tell the server about break masks, but if so the process would be identical except for the escape character (a 30x code, presumably). Henceforth I'll refer to the entity sending the break mask as the "sender" and the entity receiving the break mask as the "recipient". For the 12 bit character set SUPDUP permits, a complete break mask would be rather cumbersome, but there's a natural way to compress this. Make the first data byte a flag byte, with one flag per bucky bit, one flag for characters with no bucky bits, and two unused bits. The flag bits indicate which bucky bits the sender wants the client to try to optimize; if a flag bit is set, a break mask is supplied, if a flag is cleared, no break mask is supplied and the receiver should fall back to the default behavior (wake on every character). The most common message would presumably be one with the no-bucky-bit and control-bucky-bit flags set and all others cleared, indicating that any meta, super, or hyper characters are wakeups. In general, if a program doesn't expect to see a class of characters, it should probably wake up on them so that it can tell the user about typing errors ASAP. The flag byte is followed by a series of break masks (128 bits in 16 bytes, presumably). For completeness, this would have to be separate break masks for each case that the sender has indicated in the flag byte; ie, just because the sender wants to break on CONTROL-A and META-A doesn't mean the server wants to break on CONTROL-META-A. This is part of the reason for the flag byte, so that the sender needn't send a lot of masks that are all ones. All SUPDUP connections would still start out in character at a time remote echo mode. Setting the break mask requests local echo of any characters that are not breaks. Break characters are still handled remotely. Setting the break mask with a zero flag byte (and thus no following masks) would put the connection back in the default character at a time mode. One extension of this idea would be incremental changes to the break mask; if anybody cares enough to do it, there's always the two unused bits in the flag byte. But the above covers the basic scheme. Yes, a similar mechanism could be used in TELNET, without having to think about 12 bit characters and bucky bits, but TELNET is really not a very good model for a display terminal. SUPDUP (and the abstract model of terminals and capabilities that underlies it) is a much better model. I think the existing software speaks for itself. --Rob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709292321.AA29980@ucbvax.Berkeley.EDU] <1987092916150000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: art@ACC.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: TCP performance Message-ID: <8709292321.AA29980@ucbvax.Berkeley.EDU> Date: Tue, 29-Sep-87 20:15:00 EDT Article-I.D.: ucbvax.8709292321.AA29980 Posted: Tue Sep 29 20:15:00 1987 Date-Received: Fri, 2-Oct-87 01:02:54 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Distribution: world Organization: The ARPA Internet Lines: 26 Hey Folks, Physics won't let us go infinitely fast!!! A practical limit is probably related to distance. Lets look at the facts: TCP has a maximum window size of 65535 bytes (16 bit field). Single satellite hop is approx. 1/2 sec round trip (approx. 90 Thousand miles). Thus for satellite, max. rate is about (65535*8)/(0.5) or 1.048 Megbit/sec. Coast to Coast should be about 30 times quicker, or about 30 Megbit/sec. Of course, this is for a single TCP session, multiply for number of concurrent sessions. Art Berggreen art@acc.arpa ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2922@ames.arpa] <1987092916361400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lamaster@pioneer.arpa (Hugh LaMaster) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP performance limitations Message-ID: <2922@ames.arpa> Date: Tue, 29-Sep-87 20:36:14 EDT Article-I.D.: ames.2922 Posted: Tue Sep 29 20:36:14 1987 Date-Received: Thu, 1-Oct-87 05:44:13 EDT References: <8709290008.AA00477@ucbvax.Berkeley.EDU> Sender: usenet@ames.arpa Reply-To: lamaster@ames.UUCP (Hugh LaMaster) Organization: NASA Ames Research Center, Moffett Field, Calif. Lines: 28 In article <8709290008.AA00477@ucbvax.Berkeley.EDU> AUERBACH@CSL.SRI.COM (Karl Auerbach) writes: >Someone asked me today what are the performance limits on a TCP connection. >The situation he posited was on in which there are no intervening : >resources in the hosts, and low noise. It was further posited that An interesting question. It depends on HOW low noise your connection is. Because of acknowledgement and retransmission requirements, the faster the link, the lower noise it has to be to maintain a high delivered fraction of the raw channel speed. This is in addition to the question of the interaction of acknowledgement delay and window size, which some have mentioned, and which is also a big problem. To realize the high bandwidth in practice requires host software smart enough to adaptively distinguish between a high bandwidth low noise channel, and something like Arpanet, and adjust its behavior appropriately to either situation. Offhand, I am not sure how to do this. Anybody have any ideas? Hugh LaMaster, m/s 233-9, UUCP {topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov (Disclaimer: "All opinions solely the author's responsibility") ----MESSAGE-END---- ----MESSAGE-BEGIN---- [13000@comp.vuw.ac.nz] <1987092920320600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mark@comp.vuw.ac.nz (Mark Davies) Newsgroups: comp.protocols.appletalk,comp.protocols.tcp-ip,comp.dcom.lans Subject: Kinetics power supplies Message-ID: <13000@comp.vuw.ac.nz> Date: Wed, 30-Sep-87 00:32:06 EDT Article-I.D.: comp.13000 Posted: Wed Sep 30 00:32:06 1987 Date-Received: Sat, 3-Oct-87 08:22:22 EDT Organization: Comp Sci, Victoria Univ., Wellington, New Zealand Lines: 13 We just got a kinetics box (KFPS-2) and want to set it up to use 220v (actually 240v) power supply. The installation guide keeps refering to Appendix B for details on adapting the power supply. Unfortunately our manual has an Appendix A and an Appendix C but *NO* Appendix B (pages 63 and 64 are missing). Does anyone out there know what needs to be done? Replies by mail to the below address please. mark -- Domainised: mark@comp.vuw.ac.nz Bang form: ...!uunet!vuwcomp!mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- [262400.870930.JBVB@AI.AI.MIT.EDU] <1987092921151400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: TCP performance limitations Message-ID: <262400.870930.JBVB@AI.AI.MIT.EDU> Date: Wed, 30-Sep-87 01:15:14 EDT Article-I.D.: AI.262400.870930.JBVB Posted: Wed Sep 30 01:15:14 1987 Date-Received: Sun, 4-Oct-87 19:38:51 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 28 ... what are the performance limits on a TCP connection .... in which there are no intervening IP routers, massive availability of underlying bandwidth, massive computing resources in the hosts, and low noise. ... the hosts could be using acknowledgement strategies highly tuned for this specific situation. Thanks, --karl-- My initial estimate would be based on the media bandwidth and the memory bandwidth of the host. If the memory bandwidth of the host limits, then I would expect the data rate will be on the order of the memory bandwidth times the number of times the data must be copied on the way out (count DMA and the checksum, please). If the net bandwidth limits, I would guess somewhere between 40% and 80% of the network bandwidth, depending on the architecture (CSMA/CD maybe towards the low side, well-implemented Token Passing maybe towards the high side?). Memory bandwidth definitely dominates on the implementation I am most familiar with. We recently unrolled the TCP checksum loop, and a ~35% speed improvement there produced a ~15% overall throughput increase on memory-to-memory TCP. This got us up to 1.4 Mbits/sec between two 8Mhz AT clones on a lighty-loaded Ethernet (with 3rd-generation boards - LAN controller chip & multiple packet buffers, but no processor). 40% of a 4.3-modified Sun (3.5 Mbits/sec per a recent posting)... James B. VanBokkelen FTP Software Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [285@spdcc.COM] <1987092921170400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dyer@spdcc.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: RCTE Message-ID: <285@spdcc.COM> Date: Wed, 30-Sep-87 01:17:04 EDT Article-I.D.: spdcc.285 Posted: Wed Sep 30 01:17:04 1987 Date-Received: Fri, 2-Oct-87 02:02:14 EDT References: <8709281505.AA02244@ucbvax.Berkeley.EDU> <244@mitisft.Convergent.COM> Reply-To: dyer@spdcc.COM (Steve Dyer) Distribution: world Organization: S.P. Dyer Computer Consulting, Cambridge MA Lines: 14 I am aware of an effort at BBNCC a few years ago in support of the MINET (European MILNET) network to handle this via TELNET echo negotiation when switching between RAW, CBREAK and "cooked" terminal modes. MINET trunk lines at the time were 9600 baud, hence the desirability of minimizing micro-packet traffic induced by character echoing. I don't remember exactly how successful this was, perhaps because many of the applications they were using ("vi", InfoMail, "tcsh") preferred to run in character-at-a-time mode with echoing under the explicit control of the application. Cooked mode applications seemed to work OK, as I remember. -- Steve Dyer dyer@harvard.harvard.edu dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,m2c}!spdcc!dyer ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12338653476.59.JTW@XX.LCS.MIT.EDU] <1987092921275100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JTW@XX.LCS.MIT.EDU (John Wroclawski) Newsgroups: comp.protocols.tcp-ip Subject: Re: RCTE Message-ID: <12338653476.59.JTW@XX.LCS.MIT.EDU> Date: Wed, 30-Sep-87 01:27:51 EDT Article-I.D.: XX.12338653476.59.JTW Posted: Wed Sep 30 01:27:51 1987 Date-Received: Sun, 4-Oct-87 19:42:25 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 32 Hmm. The basic SUPDUP protocol doesn't address the remote echoing overhead problem at all, and won't do a thing for those paying per-packet charges, which is how this all started. Some (long) time ago Richard Stallman designed and implemented an extension called the SUPDUP Local Editing Protocol, which allowed a remote display-oriented program, such as EMACS, to arrange to have most operations performed at the user's local terminal, with information transferred to the remote end as required. This vastly reduces the need to send screen update information over the net, and allows bunching of update information into a few large packets rather than zillions of one-character ones. Network utilization is improved in both directions. This protocol was documented in at least one MIT AI Lab memo. I think the final version of the AI memo that described SUPDUP included it also. SUPDUP LEP is to some extend a superset of the functionality of RCTE, and could be useful for reducing the load caused by non-display-oriented programs. The basic SUPDUP protocol has some very good ideas about how to do virtual terminals, but could use some updating. A new protocol could be based on the structure of SUPDUP, maintaining the LEP and input processing concepts, but with a newer set of capability descriptors in the startup negotiation and output encodings based on the ANSI X3.64 terminal standards. This protocol would nicely address both the network efficiency concerns raised here and the problems which come up using arbitrary window-based emulators as remote terminals. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987092922020100> Received: from trout.nosc.mil by SRI-NIC.ARPA with TCP; Wed 30 Sep 87 05:01:41-PDT Received: by trout.nosc.mil (5.58/1.27) id AA02789; Wed, 30 Sep 87 05:02:01 PDT Date: Wed, 30 Sep 87 05:02:01 PDT From: wilt@trout.nosc.mil (Steven M. Wilt) To: tcp-ip@sri-nic.arpa Subject: Removal from tcp-ip relay list Message-Id: ------- Pls remove my address from the tcp-ip relay list. Thanks ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [wilt,.Wed.Sep.30.04:58:57.1987] <1987093004020100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: wilt@TROUT.NOSC.MIL (Steven M. Wilt) Newsgroups: comp.protocols.tcp-ip Subject: Removal from tcp-ip relay list Message-ID: Date: Wed, 30-Sep-87 08:02:01 EDT Article-I.D.: Posted: Wed Sep 30 08:02:01 1987 Date-Received: Sun, 4-Oct-87 21:17:27 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 ------- Pls remove my address from the tcp-ip relay list. Thanks ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709301238.AA16528@ucbvax.Berkeley.EDU] <1987093004242800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: turkewit@CCV.BBN.COM ("Kenneth A. Turkewitz") Newsgroups: comp.protocols.tcp-ip Subject: Re: RCTE Message-ID: <8709301238.AA16528@ucbvax.Berkeley.EDU> Date: Wed, 30-Sep-87 08:24:28 EDT Article-I.D.: ucbvax.8709301238.AA16528 Posted: Wed Sep 30 08:24:28 1987 Date-Received: Sun, 4-Oct-87 21:13:03 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Steve, The MINET experiment was fairly successful, but was very limited in scope. The users on the MINET were using NO screen editors, or anything else that required "special" characters to be noticed right away. As a matter of fact, all MINET applications were tailored so that a response was not needed until a linefeed was seen. Hence, MINET users were all able to run in a "line at a time" (i.e. send characters only on line feed) mode. (This only lasted for a short time, due to a minor bug that needed to be fixed in the BBN O/S kernel or the TELNET server, I forget which. By the time it was fixed, nobody really wanted to go back to the line-at-a-time mode, despite the savings on the network trunks.) Interestingly, during the planning and integration of the MINET project, we were seriously considering using RCTE (or a modification of it, known as "RACE" [Remote Application Controlled Echoing] in our planning sessions). The MINET people were not particularly interested in funding it, however. --Ken ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987093004242801> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Wed 30 Sep 87 05:25:03-PDT Date: Wed, 30 Sep 87 8:24:28 EDT From: "Kenneth A. Turkewitz" To: Steve Dyer cc: tcp-ip@SRI-NIC.ARPA Subject: Re: RCTE Steve, The MINET experiment was fairly successful, but was very limited in scope. The users on the MINET were using NO screen editors, or anything else that required "special" characters to be noticed right away. As a matter of fact, all MINET applications were tailored so that a response was not needed until a linefeed was seen. Hence, MINET users were all able to run in a "line at a time" (i.e. send characters only on line feed) mode. (This only lasted for a short time, due to a minor bug that needed to be fixed in the BBN O/S kernel or the TELNET server, I forget which. By the time it was fixed, nobody really wanted to go back to the line-at-a-time mode, despite the savings on the network trunks.) Interestingly, during the planning and integration of the MINET project, we were seriously considering using RCTE (or a modification of it, known as "RACE" [Remote Application Controlled Echoing] in our planning sessions). The MINET people were not particularly interested in funding it, however. --Ken ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]30-Sep-87.09:40:42.CERF] <1987093005400000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP performance limitations Message-ID: <[A.ISI.EDU]30-Sep-87.09:40:42.CERF> Date: Wed, 30-Sep-87 09:40:00 EDT Article-I.D.: <[A.ISI.EDU]30-Sep-87.09:40:42.CERF> Posted: Wed Sep 30 09:40:00 1987 Date-Received: Fri, 2-Oct-87 02:40:41 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 59 Karl, I have been doing some work in this area to predict potential performance at 100 Mb/s FDDI rates. First, you can expect a TCP to execute about 1000-1200 instructions per packet, assuming all is well. Some of this is checksum. In fact, I recall some early statistics in which the checksum alg took up 40% of the CPU cycles for processing incoming segments of TCO. I am lumping IP level processing into TCP in the 1000-1200. This is absolutely a WAG - so anyone with some hard data on instruction count is most welcome to provide better info. Roundtrip time and window size limitations affect performance with respect to total throughput, all other things ignored. Suppose you were operating at 10MB (megabytes)/second and had a prop. delay of 10 microseconds on the ring. With no constraints, and using 1000 byte packets, you would be sending 10,000 packets/second to achieve full throughput. That gives you 100 microseconds worth of insruction time. At 14 MIPs, that is 1400 instructions. So, if you did nothing else but TCP/IP, you might make it, with respect to instruction rate. Window size limitations: you can have 65,536 bytes outstanding and at 10 MB/sec, it takes 6.5 ms to send them. Assuming you can send the ack in the 100 microseconds you have to "process" the packet, it takes 10 microseconds + 100 + 10 = 120 usec (2 X propagation delay plus processing time) to get the ACK. Even asusming another 100 usec to process the ACK, that 220 usec worth of window needed, minimum. That's only 2200 bytes - so even a factor of 10 increase is well within the window capacity of the TCP. The killer in all this is propagation and round-trip delay. It doesn't take much to cause the window requirment for full bandwidth to exceed the maximum allowed window of outstanding bytes. For example, a round-trip time of 10 ms (the prop delay of only 1000 miles, one way!) requires a window of over 100KB to maintain full capacity at 10MB/sec. What these very sketchy and rough numbers suggest is that window-based schemes won't be very satisfactory for long haul, long delay, very high speed nets. Flow control based on rates is needed, rather than on round-trip acks/permissions - of course, this is precisely the kind of thinking that I believe underlies the work that Dave Clark has been doing with NETBLT (Dave, holler if I have put words/thoughts into your work inappropriately). To sum up, TCP can probably be made to work well in low delay systems at pretty high speeds, maybe up to 100 Mbit/sec, but probably not at a gigabit and probably not at long haul cross country at 100's of megabits/sec. By the way, most of these same considerations apply to ISO TP, in my estimation. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987093005400001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 30 Sep 87 07:03:12-PDT Date: 30 Sep 1987 09:40-EDT Sender: CERF@A.ISI.EDU Subject: Re: TCP performance limitations From: CERF@A.ISI.EDU To: AUERBACH@CSL.SRI.COM Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]30-Sep-87 09:40:42.CERF> In-Reply-To: The message of Mon 28 Sep 87 17:00:32-PDT from Karl Auerbach Karl, I have been doing some work in this area to predict potential performance at 100 Mb/s FDDI rates. First, you can expect a TCP to execute about 1000-1200 instructions per packet, assuming all is well. Some of this is checksum. In fact, I recall some early statistics in which the checksum alg took up 40% of the CPU cycles for processing incoming segments of TCO. I am lumping IP level processing into TCP in the 1000-1200. This is absolutely a WAG - so anyone with some hard data on instruction count is most welcome to provide better info. Roundtrip time and window size limitations affect performance with respect to total throughput, all other things ignored. Suppose you were operating at 10MB (megabytes)/second and had a prop. delay of 10 microseconds on the ring. With no constraints, and using 1000 byte packets, you would be sending 10,000 packets/second to achieve full throughput. That gives you 100 microseconds worth of insruction time. At 14 MIPs, that is 1400 instructions. So, if you did nothing else but TCP/IP, you might make it, with respect to instruction rate. Window size limitations: you can have 65,536 bytes outstanding and at 10 MB/sec, it takes 6.5 ms to send them. Assuming you can send the ack in the 100 microseconds you have to "process" the packet, it takes 10 microseconds + 100 + 10 = 120 usec (2 X propagation delay plus processing time) to get the ACK. Even asusming another 100 usec to process the ACK, that 220 usec worth of window needed, minimum. That's only 2200 bytes - so even a factor of 10 increase is well within the window capacity of the TCP. The killer in all this is propagation and round-trip delay. It doesn't take much to cause the window requirment for full bandwidth to exceed the maximum allowed window of outstanding bytes. For example, a round-trip time of 10 ms (the prop delay of only 1000 miles, one way!) requires a window of over 100KB to maintain full capacity at 10MB/sec. What these very sketchy and rough numbers suggest is that window-based schemes won't be very satisfactory for long haul, long delay, very high speed nets. Flow control based on rates is needed, rather than on round-trip acks/permissions - of course, this is precisely the kind of thinking that I believe underlies the work that Dave Clark has been doing with NETBLT (Dave, holler if I have put words/thoughts into your work inappropriately). To sum up, TCP can probably be made to work well in low delay systems at pretty high speeds, maybe up to 100 Mbit/sec, but probably not at a gigabit and probably not at long haul cross country at 100's of megabits/sec. By the way, most of these same considerations apply to ISO TP, in my estimation. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870930102609.9.DCP@KOYAANISQATSI.S4CC.Symbolics.COM] <1987093006260000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: SUPDUP protocol Message-ID: <870930102609.9.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Wed, 30-Sep-87 10:26:00 EDT Article-I.D.: KOYAANIS.870930102609.9.DCP Posted: Wed Sep 30 10:26:00 1987 Date-Received: Fri, 2-Oct-87 03:27:43 EDT References: <12338315541.10.BILLW@MATHOM.CISCO.COM> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 23 Date: Mon 28 Sep 87 15:31:31-PDT From: William Westfield ... What it amounts to is that most operating systems are STILL dealing with the terminal as if it were a printer, and that this probably has to change before a smarter virtual terminal protocol can be defined. That's an interesting point. I can name at least two operating systems that natively know about display terminals and considered printing terminals as a (crippled) subset. I believe they knew this as long as 15 years ago. They are: ITS (developed at the MIT AI lab) and, if memory serves, WAITS (developed at Stanford). There are things in ITS that are profound even today, since as you say, "most OSs are STILL" wedged about terminal==printer. SRA and JTW aren't talking through their teeth; they are familiar with and have access to existing systems that know about display terminals and have for many years. The cynic in me says you won't see much real improvement in Unix or VMS or whatever unless and until their owners bite the bullet, commit to entering the 1980s (from the 1960s), and pour money into the development hole. I would actually suggest they try to be visionaries and enter the 1990s. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709301649.AA20519@ucbvax.Berkeley.EDU] <1987093008515100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: GLM@IPGUNIV.BITNET (Gianfranco Galmacci) Newsgroups: comp.protocols.tcp-ip Subject: Re: RCTE Message-ID: <8709301649.AA20519@ucbvax.Berkeley.EDU> Date: Wed, 30-Sep-87 12:51:51 EDT Article-I.D.: ucbvax.8709301649.AA20519 Posted: Wed Sep 30 12:51:51 1987 Date-Received: Sun, 4-Oct-87 21:35:53 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 2 please remove me Acknowledge-To: ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12338789015.10.BILLW@MATHOM.CISCO.COM] <1987093009522400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BILLW@MATHOM.CISCO.COM (William Westfield) Newsgroups: comp.protocols.tcp-ip Subject: Re: RCTE Message-ID: <12338789015.10.BILLW@MATHOM.CISCO.COM> Date: Wed, 30-Sep-87 13:52:24 EDT Article-I.D.: MATHOM.12338789015.10.BILLW Posted: Wed Sep 30 13:52:24 1987 Date-Received: Sun, 4-Oct-87 22:43:36 EDT References: <244@mitisft.Convergent.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 The basic idea is to have the kernel (virtual terminal driver) inform the telnet daemon when it *would be* doing immediate character echo, and not do it. The daemon turns this information into echo negotiation, which the client (hopefully) heeds. This results in speeded echo response in (for example) un*x "cooked" mode, plus a reduction in packet traffic. This means that the client must send every character immediately to the host, and then wait (for an indeterminate time) for a response from the host that indicates whether the next characters should not be echoed. (This is in the worst case, of course. If you are willing to assume that when the client is doing local echo, it is doing local echo of ALL characters, and that it doesn't matter if the client accidently echos some characters it should not have or doesn't echo some characters it should have, it may indeed help...) Bill Westfield cisco Systems ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2939@ames.arpa] <1987093011322900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lamaster@pioneer.arpa (Hugh LaMaster) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP performance limitations Message-ID: <2939@ames.arpa> Date: Wed, 30-Sep-87 15:32:29 EDT Article-I.D.: ames.2939 Posted: Wed Sep 30 15:32:29 1987 Date-Received: Sun, 4-Oct-87 22:45:07 EDT References: <[A.ISI.EDU]30-Sep-87.09:40:42.CERF> Sender: usenet@ames.arpa Reply-To: lamaster@ames.UUCP (Hugh LaMaster) Organization: NASA Ames Research Center, Moffett Field, Calif. Lines: 26 In article <[A.ISI.EDU]30-Sep-87.09:40:42.CERF> CERF@A.ISI.EDU writes: > >What these very sketchy and rough numbers suggest is that >window-based schemes won't be very satisfactory for long haul, >long delay, very high speed nets. Flow control based on rates is needed, >rather than on round-trip acks/permissions - of course, this is precisely >the kind of thinking that I believe underlies the work that >Dave Clark has been doing with NETBLT (Dave, holler if I >have put words/thoughts into your work inappropriately). > I have seen/heard references to rate based flow control before - but I haven't seen (or maybe remembered) what the idea is. Is there a summary somewhere or could someone summarize the basic idea? (Is there an RFC? etc.) Hugh LaMaster, m/s 233-9, UUCP {topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov (Disclaimer: "All opinions solely the author's responsibility") ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709301937.AA11753@TOTO.MIT.EDU] <1987093011374900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mar@ATHENA.MIT.EDU Newsgroups: comp.protocols.tcp-ip Subject: closing half-open connections Message-ID: <8709301937.AA11753@TOTO.MIT.EDU> Date: Wed, 30-Sep-87 15:37:49 EDT Article-I.D.: TOTO.8709301937.AA11753 Posted: Wed Sep 30 15:37:49 1987 Date-Received: Sun, 4-Oct-87 23:00:44 EDT References: <8709291530.AA13517@aplpy.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 I assume that Pyramid release 3.1 has the Berkeley 4.2 network layer. In this case you can force the connections closed. I wrote a program to do this a while back, but it's full of unix source I shouldn't redistribute to someone without a source license... To do it by hand, run netstat -A and find the address of the PCB for the connection. This is the hex number in the first column). Then start adb with adb -w -k /vmunix /dev/kmem and zero out the short word 8 bytes past the address of the PCB (this is the size of the offset on the vax, it may vary on the Pyramid. You can check it by looking at struct tcpcb in , and finding the offset to t_state) address+8/w 0 this forces the state of this connection to CLOSED. The next time a timer fires for that connection, it will notice that it is in the closed state and deallocate it. You can exit adb with $q I suspect that this would work on 4.3 based network layers also, although the bug shouldn't exist there that requires it. -Mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]30-Sep-87.18:26:05.CERF] <1987093014260000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: RCTE Message-ID: <[A.ISI.EDU]30-Sep-87.18:26:05.CERF> Date: Wed, 30-Sep-87 18:26:00 EDT Article-I.D.: <[A.ISI.EDU]30-Sep-87.18:26:05.CERF> Posted: Wed Sep 30 18:26:00 1987 Date-Received: Mon, 5-Oct-87 00:51:04 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 The MCI Mail system, which runs on an X.25 version of the BBN C.30 packet net, is a line-at-a-time system which forwards on CR and does intra-line editing at the PAD (TAC). Most users preferred that mode because of the immediate echoing response. Remote echo mode was simply not acceptable. Of course, many of the long haul lines were 9.6 rather than 50 kb/s and this contributed to increased "stickiness" of the echoing. On the whole, I felt strongly for that particular application the line at a time mode was best - presuming, of course, that most of the real text editing was done off-line with a PC and that the interaction was mostly for preparation of addressees. Eventually, PC packages like Lotus Express and Desktop Express for the IBM PC and Apple Macintosh were produced which largely decoupled the users from any direct interaction exposing the network. Most users of these packages prefer not to go back to the direct mode at all, I believe. The point of all this is to argue that localizing much of the interaction which would otherwise require char-by-char network support seems preferable and in keeping with trends towards more powerful, local workstations using background processes to handle network activities. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987093018283700> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Wed 30 Sep 87 09:30:44-PDT Received: from IPGUNIV.BITNET by WISCVM.WISC.EDU ; Wed, 30 Sep 87 11:32:11 CDT Return-path: GLM%IPGUNIV.BITNET@WISCVM.ARPA Received: by IPGUNIV (Mailer X1.24) id 3007; Wed, 30 Sep 87 17:29:06 SET Date: Wed, 30 Sep 87 17:28:37 SET From: Gianfranco Galmacci Subject: Re: RCTE To: TCP-IP@SRI-NIC.ARPA In-Reply-To: Message of Tue, 29 Sep 87 11:07:26 CDT from please remove me Acknowledge-To: ----MESSAGE-END---- ----MESSAGE-BEGIN---- [247@mitisft.Convergent.COM] <1987093019531500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: andrew@mitisft.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: closing half-open connections Message-ID: <247@mitisft.Convergent.COM> Date: Wed, 30-Sep-87 23:53:15 EDT Article-I.D.: mitisft.247 Posted: Wed Sep 30 23:53:15 1987 Date-Received: Sat, 3-Oct-87 12:03:27 EDT References: <8709291530.AA13517@aplpy.ARPA> Distribution: world Organization: Convergent Technologies, San Jose, CA Lines: 33 While I dont have any suggestions for closing existing half-open connections (although I think someone posted something awhile back), I do have a scenario which I have seen cause this, which can be traced to an ambiguity in the RFC... Scenario: 1) Server sends FIN, gets ACK, enters FIN_WAIT_2. 2) Client sends a bunch of data. 3) Server's window size goes to zero due to normal flow control. 4) Client closes connection. At this point, client has data buffered, and needs a window update. FIN hasnt been sent since data is pending. 5) Client is now in LAST_ACK. However, he ignores window updates, looking only for ACK of FIN he hasnt sent! The connection is effectively idle. Now, the RFC says all data should be sent after a close (pgs 49 & 61), and that when a segment arrives in LAST_ACK state only the ACK of FIN should be checked for (pg 73). 4.3 seems to have "fixed" this problem by both flushing data on a close and putting a timer on FIN_WAIT_2, along with having just about everybody use "linger mode" where the close delays till the data drains (not the default). I fixed it by looking at window updates during LAST_ACK; not exactly spec, but harmless (apparently) in the normal cases.... Andrew ----MESSAGE-END---- ----MESSAGE-BEGIN---- [17488@teknowledge-vaxc.ARPA] <1987093023221500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mkhaw@teknowledge-vaxc.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: closing half-open connections Message-ID: <17488@teknowledge-vaxc.ARPA> Date: Thu, 1-Oct-87 03:22:15 EDT Article-I.D.: teknowle.17488 Posted: Thu Oct 1 03:22:15 1987 Date-Received: Sat, 3-Oct-87 06:15:35 EDT References: <8709301937.AA11753@TOTO.MIT.EDU> Distribution: world Organization: Teknowledge, Inc., Palo Alto CA Lines: 84 Here's a /bin/sh driven adb script posted to the net a while back that forces a socket to close: <--- cut here ---> #! /bin/sh # original from cdjohns@NSWC-G.ARPA # # TIMETODEATH expressed in decimal instead of hex # -- mkhaw@teknowledge-vaxc.arpa # Use this script to force sockets in FIN_WAIT_2 state to close. # It works by setting the 2MSL timer in the TCP Protocol Control Block (PCB) # to a non-zero value. The kernel then begins to decrement this value until # it reaches zero, at which point the kernel forces a close on the socket and # deletes the TCP PCB. If both sides of the connection are hung, clearing one # side will possibly clear the other. # MSLOFFSET is the offset in the tcpcb record for the 2MSL timer. # describes the tcpcb record. # This value is the number of bytes offset, expressed in hexadecimal. MSLOFFSET=10 # TIMETODEATH is the number of half seconds until the connection is # closed. This value is expressed in decimal and must be greater # than zero. TIMETODEATH=06 # Display netstat to get PCB addresses (first column). echo 'Active connections PCB Proto Recv-Q Send-Q Local Address Foreign Address (state)' netstat -A | fgrep FIN_WAIT_2 echo echo -n 'PCB address to terminate? ' read addr echo # Use adb on kernel to display the PCB of the specified address adb -k /vmunix /dev/mem << SHAR_EOF $addr\$ Mike Khaw -- internet: mkhaw@teknowledge-vaxc.arpa usenet: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303 ----MESSAGE-END----