|
|
ARCHIVE: TCP-IP Distribution List - Archives (1987)
DOCUMENT: TCP-IP Distribution List for April 1987 (313 messages, 148431 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1987/04.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Wed, 1-Apr-87 09:39:52 EST From: mckee@MITRE.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Peak User Estimate
Based on some envelope calculations, described below, I estimate
that the peak number of simultaneous users is 10% of the potential
users. Is this estimate in accord with your experience?
The system I use here at MITRE is a VAX 8600 running Ultrix. I have
recently had occasion to be interested in the peak number of
simultaneous users as a percentage of the number of possible users.
So, on 24 March, I copied the /usr/users file and found 551 entries,
some of which had not logged-in since 1985! Recognizing that some user
accounts simply forward mail to another system, I deleted every entry
whose last login was 28 February, or earlier. That left 191 users that
had logged-in at least once during the period 1-24 March.
Over the past several months I have, at unplanned intervals, run the
Unix "who" command that lists all logged-in users. The usual response
is 10 to 15 users; very rarely does the number equal or exceed 20. The
estimate made above follows from this data.
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Wed, 1-Apr-87 10:15:00 EST From: GBELING@A.ISI.EDU.UUCP To: mod.protocols.tcp-ip Subject: IP over x.25
hello collegues, we are running here a connection to the arpanet using the PTT's datex-p (i.e. x.25) as a transatlantic transport medium. To do so we have connected TELNET/TCP/IP over x.25 i.e. encapsulated the IP datagrams into x.25-packets. Up to some time ago this worked fairly well and reliable and fast (up to 2.000 bps over a 4.8 kb/s "line"). We reach the arpanet at the van-gateway in boston. Since heavy congestion occurs in the arpa/milnet we have a special poroblem: If for some reason the x.25 virtual connection is idle for 2 minutes the van-gateway closes the connection and cannot reopen it: we have to do this because we have to pay the x.25 charges. In the case that we are reading data from the other side and have acked all segments properly the connection is broken and our TCP has to wait until the user timeout cancels the (tcp) connection on our side - what the far-end tcp does we do not know. This happens sometimes when the far tcp does not do retransmissions or so slowly that in the intermediate time x.25 cuts us off. Ip is developed for the case that the underlying connection is a permannt available one i.e. no open or close needed ! If we look to the protocol suite properly there is no way to signal the broken x.25 connection to the user of telnet so that he can react. therefore we think of to reopen the x.25 VC automatically when the other side closes it. this has the disadvantage that we reopen it also when the tcp-connection has finished because x.25 does not know something about tcp-connections. The peculiar problem is that we have to pay for each OPEN of a VC (and afterwards for the time it is open: 5pfg for each open, 15pfg per minute). The problem will become even more complicated when several tcp-connections are multiplexed onto one x.25-virtual circuit or there are several x.25 VCs open at the same time. How did others solve the problem to reopen broken x.25VCs when a tcp-connection to close the connection? thanks gerd beling
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 1987 10:15-EST From: GBELING@A.ISI.EDU To: tcp-ip@SRI-NIC.ARPA Subject: IP over x.25
hello collegues, we are running here a connection to the arpanet using the PTT's datex-p (i.e. x.25) as a transatlantic transport medium. To do so we have connected TELNET/TCP/IP over x.25 i.e. encapsulated the IP datagrams into x.25-packets. Up to some time ago this worked fairly well and reliable and fast (up to 2.000 bps over a 4.8 kb/s "line"). We reach the arpanet at the van-gateway in boston. Since heavy congestion occurs in the arpa/milnet we have a special poroblem: If for some reason the x.25 virtual connection is idle for 2 minutes the van-gateway closes the connection and cannot reopen it: we have to do this because we have to pay the x.25 charges. In the case that we are reading data from the other side and have acked all segments properly the connection is broken and our TCP has to wait until the user timeout cancels the (tcp) connection on our side - what the far-end tcp does we do not know. This happens sometimes when the far tcp does not do retransmissions or so slowly that in the intermediate time x.25 cuts us off. Ip is developed for the case that the underlying connection is a permannt available one i.e. no open or close needed ! If we look to the protocol suite properly there is no way to signal the broken x.25 connection to the user of telnet so that he can react. therefore we think of to reopen the x.25 VC automatically when the other side closes it. this has the disadvantage that we reopen it also when the tcp-connection has finished because x.25 does not know something about tcp-connections. The peculiar problem is that we have to pay for each OPEN of a VC (and afterwards for the time it is open: 5pfg for each open, 15pfg per minute). The problem will become even more complicated when several tcp-connections are multiplexed onto one x.25-virtual circuit or there are several x.25 VCs open at the same time. How did others solve the problem to reopen broken x.25VCs when a tcp-connection to close the connection? thanks gerd beling
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Wed, 1-Apr-87 10:48:46 EST From: LYNCH@A.ISI.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: interesting new product I ran across
John, Sounds like it has almost allof the features one could use! But, as Billy Brackenridge would say:" PRICE IS TECHNICAL INFORMATION. So, let me know by the drop deadline and I'll order up a bunch. Dan PS. I really hope you don't run out of those EBCDIC decoder rings... -------
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 1987 10:48:46 EST From: Dan Lynch <LYNCH@A.ISI.EDU> To: John Romkey <ROMKEY@XX.LCS.MIT.EDU> Cc: tcp-ip@SRI-NIC.ARPA, pcip@LOUIE.UDEL.EDU, LYNCH@A.ISI.EDU Subject: Re: interesting new product I ran across
John, Sounds like it has almost allof the features one could use! But, as Billy Brackenridge would say:" PRICE IS TECHNICAL INFORMATION. So, let me know by the drop deadline and I'll order up a bunch. Dan PS. I really hope you don't run out of those EBCDIC decoder rings... -------
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Wed, 01 Apr 87 09:25:57 +0000 From: Jon Crowcroft <jon@Cs.Ucl.AC.UK> To: Chris Perry <cperry@gateway.mitre.org> Cc: tcp-ip@sri-nic.arpa Subject: Re: talking of and to gateways and bridges
Chris, ROS stands for Remote OperationS, and REX stands for Remote EXexcution. They are part of the ECMA (European Computer Manufacturers Association) input to draft standards work on distributed computing. REX is a Birrel & Nelson type 'minimum packet' transaction transport protocol, whilst ROS uses ASN (Abstract Sysntax Notation) as a presentation layer to to define call/reply/error messages and parameters and to provide machine independance of call and reply parameter representation. The ANSA (Advanced Network Systems Architecture) research group have put a lot of work into their design. The goal is to provide a system where code for client/server model interactions may be generated automatically (RPC type work), but to allow for other types of interaction too. jon
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Wed, 1-Apr-87 17:40:49 EST From: rbbb@rice.EDU.UUCP To: mod.protocols.tcp-ip Subject: Mail "direct to machines"
narten@purdue.edu says: > mailbox. Presumably, as domain names get extended, we will be able to > do that. Any mail you send to a user can go directly to the machine > where the his/her mailbox resides. No forwarding at the site would be > needed. I may misunderstand you, but how can you tell where my mailbox resides? If you look at my "Message-Id", you might guess that you could send to "rbbb@proserpina.rice.edu", and you would be wrong. I read my mail at "titan.rice.edu", but you should just send it to "rice.edu", and let it be forwarded to whereever I happen to currently live. It is difficult to propagate precise information about my whereabouts to ALL the machines on our net, and much more difficult when you consider that I am certainly not the only user here. It is much much simpler to have every machine except the one where my mailbox resides boot my mail to "rice.edu", and let "rice.edu" forward it to my home. Obviously, we take great pains to keep rice.edu up and running, but it is no more vital than our gateway, our line to the IMP in Austin, or the IMP itself. I don't see how extended domain names will help this. David
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Wed, 1-Apr-87 18:02:35 EST From: Crispin@SUMEX-AIM.STANFORD.EDU.UUCP To: mod.protocols.tcp-ip Subject: totally cretinous domain lossage
A major Internet mailing list failed today because the domain system is
broken for hosts in Norway. Specifically, the hosts that were named
OSLO-VAX.ARPA and NTA-VAX.ARPA have IN-ADDR records on their host addresses
that return the names ifi.UIO.NO and tor.NTA.NO respectively. However, the
domain system does not recognize either of the mumble.NO names!
I sure to hell wish that organizations would coordinate their IN-ADDR
entries with their name entries. Please don't tell me not to use IN-ADDR
entries -- I know it's a kludge and as soon as the developers of the TOPS-20
domain software give me a "translate name to fully-qualified domain name"
function I'll use it.
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Wed, 01 Apr 87 10:31:41 O From: Henry Nussbacher <HANK%BARILVM.BITNET@wiscvm.wisc.edu> To: tcp-ip@sri-nic.ARPA Subject: Remote access in Bitnet
(Caveat - This description is primarily for people who have no idea how Bitnet works.) Greg, The concept of remote access doesn't exist in Bitnet. The protocols in Bitnet are as follows: 1) One-way File Transfer - any user is allowed to send a file to any other user. Since the file ends up in the destination users spool system (or some emulation thereof) there is no problem with access control. 2) Interactive Message - any user can send a one line message (max 160 characters) to any other user. All you need to know is the destination user and node. If the user is not logged on or a link is down you are told so. Based on these two primitives - Bitnet has built various other pseudo-protocols. From #1 above - we are able to do mail, list explosion, computer conferencing, general file transfer. From #2 above, Bitnet has developed a CB (Chat) system. By combined both of the basic primitives above, a file server can be set up at any node that will trap incoming 'Interactive Messages' - which contain a command and process the command and send the results back to the user via the 'One-Way File Transfer' mechanism. This method allows users to sit at their machine and issue commands like DIR or LIST to some remote file server and then issue some SEND commands to retrieve the files they want. There is no need in that case to do any sort of remote connect (anonymous FTP). Most servers (200+) in Bitnet also accept transactions via files or RFC822 mail. Lately, various servers in Arpanet have decided that is also a 'clever' thing to have, so we have things like archive-request@simtel20.arpa and service@sri-nic.arpa popping up (I expect more before the end of th year). So to answer your question: > a remote file they own They cannot access it. Yup would be nice and that is just one reason why Bitnet should convert to Tcp/Ip. Incidentally, there is a program I distribute in Bitnet that allows this remote access to a file the person owns but it is a private convention. The program runs as a task (and therefore must be running when the remote user wants access to his/her files). and the user needs to set up a remote access password. It uses the Interactive Message Primitive to send and receive data, and each command you want executed on the remote host must be prefixed with your remote pswd. Not as elegent as TELNET but when the entire concept of TELNET doesn't exist it is the best one can do. > a remote file they don't own, but is not protected Only if the file is available via a remote file server can they access it. > a remote file they don't own, but is protected They can't access it. Hope this helps. Hank
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Wed, 1-Apr-87 20:31:00 EST From: CERF@A.ISI.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits
Stu, one little observation. A single collision in your tapemobile would do rather more damage than the typical collision on an ethernet. Shows why putting all your bits in one packet isn't a good policy... Vint
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 1987 20:31-EST From: CERF@A.ISI.EDU To: GROSSMAN@SIERRA.STANFORD.EDU Cc: imagen!apolling!geof@DECWRL.DEC.COM, tcp-ip@SRI-NIC.ARPA Subject: Re: Station wagon full of bits
Stu, one little observation. A single collision in your tapemobile would do rather more damage than the typical collision on an ethernet. Shows why putting all your bits in one packet isn't a good policy... Vint
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Wed, 1-Apr-87 21:16:00 EST From: CERF@A.ISI.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits
Bob, just came across your message about the station wagon full of bits - amazing! You and I had nearly the identical reaction as you'll see when you read TCP-IP and catch my message [sometimes I think I should read my mail backwards...]. Vint
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 1987 21:16-EST From: CERF@A.ISI.EDU To: hinden@CCV.BBN.COM Cc: GROSSMAN@SIERRA.STANFORD.EDU, tcp-ip@SRI-NIC.ARPA Subject: Re: Station wagon full of bits
Bob, just came across your message about the station wagon full of bits - amazing! You and I had nearly the identical reaction as you'll see when you read TCP-IP and catch my message [sometimes I think I should read my mail backwards...]. Vint
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Wed, 1-Apr-87 21:28:00 EST From: CERF@A.ISI.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits
One of the important features of X.25 and other packet-oriented services (and of DOD TCP/IP or ISO TP/IP, etc.) is the ability to support many simultaneous virtual connections. The ISDN facilities will not replace that functionality if level 3 is erased and only level 2 remains and only supports a single connection at a time. ISDN does provide for a packet mode interface which is basically a level 3 construct. I do not see that the pt-pt 64 kb/s service from ISDN will render the multi-connection modes of operation useless. Vint
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 1987 21:28-EST From: CERF@A.ISI.EDU To: mckee@MITRE.ARPA Cc: tcp-ip@SRI-NIC.ARPA, m15368%mwvm@MITRE.ARPA Subject: Re: Station wagon full of bits
One of the important features of X.25 and other packet-oriented services (and of DOD TCP/IP or ISO TP/IP, etc.) is the ability to support many simultaneous virtual connections. The ISDN facilities will not replace that functionality if level 3 is erased and only level 2 remains and only supports a single connection at a time. ISDN does provide for a packet mode interface which is basically a level 3 construct. I do not see that the pt-pt 64 kb/s service from ISDN will render the multi-connection modes of operation useless. Vint
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Wed, 1-Apr-87 21:32:00 EST From: CERF@A.ISI.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: ICMP message caching
Steve, there will be some howls, but I think the idea of ICMP caching to be worth exploring. We are surely in agreement that the more knowledge you can obtain about the Internet condition, the better you can, at the source, make decisions about traffic routing, retransmission, attempts to set-up connections, etc. I am sure this subject has come up before - some folks were uncomfortable because it seemed to smack of protocol boundary crossing - Dave mIlls mentioned a similar idea relative to caching such information th the gateways, too. Let's see what comments your notion uncovers! Vint
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 1987 21:32-EST From: CERF@A.ISI.EDU To: steve@BRILLIG.UMD.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: ICMP message caching
Steve, there will be some howls, but I think the idea of ICMP caching to be worth exploring. We are surely in agreement that the more knowledge you can obtain about the Internet condition, the better you can, at the source, make decisions about traffic routing, retransmission, attempts to set-up connections, etc. I am sure this subject has come up before - some folks were uncomfortable because it seemed to smack of protocol boundary crossing - Dave mIlls mentioned a similar idea relative to caching such information th the gateways, too. Let's see what comments your notion uncovers! Vint
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Wed, 1-Apr-87 21:36:00 EST From: CERF@A.ISI.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Tcp/Ip vs a store & forward network
Hank, we didn't do it because I think we didn't think it was necessary but that's because we started with just one network and tried to extend the earlier services to the Internet. The mail forwarders are really store/forward when you think about it. Also, you need all the mechanisms for error reporting that the mail system has in it to recover from failures. Vint
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 1987 21:36-EST From: CERF@A.ISI.EDU To: HANK%BARILVM.BITNET@WISCVM.WISC.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Tcp/Ip vs a store & forward network
Hank, we didn't do it because I think we didn't think it was necessary but that's because we started with just one network and tried to extend the earlier services to the Internet. The mail forwarders are really store/forward when you think about it. Also, you need all the mechanisms for error reporting that the mail system has in it to recover from failures. Vint
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: Wed, 1-Apr-87 21:44:00 EST From: CERF@A.ISI.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: GOSIP vs TCP/IP
Steve (Kille), I merely wanted to point out that you need something above the X.25 level to do recovery, if you care, after a reset. Vint
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 1987 21:44-EST From: CERF@A.ISI.EDU To: Steve.Kille@CS.UCL.AC.UK Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: GOSIP vs TCP/IP
Steve (Kille), I merely wanted to point out that you need something above the X.25 level to do recovery, if you care, after a reset. Vint
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: Wed, 1-Apr-87 21:58:00 EST From: CERF@A.ISI.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Peak User Estimate
10% represents a high usage rate. MCI Mail had 16000 users/VAX but only a small % (0.5-1%) were ever trying to get on at once. Vint
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 1987 21:58-EST From: CERF@A.ISI.EDU To: mckee@MITRE.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Peak User Estimate
10% represents a high usage rate. MCI Mail had 16000 users/VAX but only a small % (0.5-1%) were ever trying to get on at once. Vint
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Thu, 2-Apr-87 01:21:33 EST From: chris@SPAM.ISTC.SRI.COM.UUCP To: mod.protocols.tcp-ip Subject: New source for Imagen laser printer memory boards.
I, recently had the oppertunity to evaluate a memory board for the Imagen IP/II processors. Since this is the first I had heard of an alternative source for Imagen memory I thought I'd share the info with the net. The company's name is Kortex Systems and incase you want to contact them their phone numbers are (415)-961-4411 or (415)-969-4053. They sell both a 4 meg and a 3 Meg board, I tried out the 4 Meg board in our 8/300 and our 3320 Imagen printers, both printers sit on our local ether net. In the past large jobs (100+ pages) would come out in reverse order and you would have to collilate the pages manually, with the 4 meg board in the system I couldn't find a listing large enough to use up all of the memory. We used the board in both systems for a week and saw no problems with it. The 4 Meg board retails for $1795 with discouts for non-profit and educational groups. The last time I checked the largest board Imagen sold was a 3 Meg one and it was going for $1900. Chris
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Thu, 2-Apr-87 07:29:28 EST From: tsuchiya@GATEWAY.MITRE.ORG.UUCP To: mod.protocols.tcp-ip Subject: Re: Packet network reliability
> BBN gets around these two disadvantages at a cost. The Milnet for instance > is gettingvery large, very fast. I don't know the formula for computing the > amount of bandwidth required for the internal routing updates, but I would > suspect it would go up exponentially with the number of nodes(and connectivity > of them). If anybody knows the numbers I'd like to have them. BBN C-30 based networks use an efficient flooding scheme to send routing updates. Each update crosses each link twice, the second time as a robust acknowledgement. Link overhead is therefore linear with the number of nodes. Better still, the algorithm they use to compute routes when a change is received performs on the order of the average hop length of all paths, estimated at log N/log(c-1) where N is number of nodes and c is connectiviey. See paper by John McQuillan, Ira Richer, and Eric Rosen, "The New Routing Algorithm for the ARPANET," IEEE Transactions on Communications, Vol. COM-28, No. 5, May 1980. Paul Tsuchiya tsuchiya@gateway.mitre.org The MITRE Corp. tsuchiya@mitre-gateway.arpa
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Thu, 2-Apr-87 07:57:04 EST From: HANK@BARILVM.BITNET.UUCP To: mod.protocols.tcp-ip Subject: Bitnet protocols
I sent this yesterday and I never saw it come back so I have a feeling it got lost on its way: (Caveat - This description is primarily for people who have no idea how Bitnet works.) Greg, The concept of remote access doesn't exist in Bitnet. The protocols in Bitnet are as follows: 1) One-way File Transfer - any user is allowed to send a file to any other user. Since the file ends up in the destination users spool system (or some emulation thereof) there is no problem with access control. 2) Interactive Message - any user can send a one line message (max 160 characters) to any other user. All you need to know is the destination user and node. If the user is not logged on or a link is down you are told so. Based on these two primitives - Bitnet has built various other pseudo-protocols. From #1 above - we are able to do mail, list explosion, computer conferencing, general file transfer. From #2 above, Bitnet has developed a CB (Chat) system. By combined both of the basic primitives above, a file server can be set up at any node that will trap incoming 'Interactive Messages' - which contain a command and process the command and send the results back to the user via the 'One-Way File Transfer' mechanism. This method allows users to sit at their machine and issue commands like DIR or LIST to some remote file server and then issue some SEND commands to retrieve the files they want. There is no need in that case to do any sort of remote connect (anonymous FTP). Most servers (200+) in Bitnet also accept transactions via files or RFC822 mail. Lately, various servers in Arpanet have decided that is also a 'clever' thing to have, so we have things like archive-request@simtel20.arpa and service@sri-nic.arpa popping up (I expect more before the end of th year). So to answer your question: > a remote file they own They cannot access it. Yup would be nice and that is just one reason why Bitnet should convert to Tcp/Ip. Incidentally, there is a program I distribute in Bitnet that allows this remote access to a file the person owns but it is a private convention. The program runs as a task (and therefore must be running when the remote user wants access to his/her files). and the user needs to set up a remote access password. It uses the Interactive Message Primitive to send and receive data, and each command you want executed on the remote host must be prefixed with your remote pswd. Not as elegent as TELNET but when the entire concept of TELNET doesn't exist it is the best one can do. > a remote file they don't own, but is not protected Only if the file is available via a remote file server can they access it. > a remote file they don't own, but is protected They can't access it. Hope this helps. Hank
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: 2 Apr 1987 12:33:26 CST From: AFDDN.TCP-IP@GUNTER-ADAM.ARPA To: tsuchiya@MITRE-GATEWAY.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: Packet network reliability
Paul, On the C/30 algorithm, I believe there are two occurences which can generate an update. One is the expiration of some timer which I've been told is 30 secs. I seem to remember at one time the limit being around 15 secs. The other occurence is in the case where a link is determined to be down. I made the assumption that as the total number of nodes and the connectivity increases then the probability of link problems goes up. Would it increase linearly? Would be an interesting study. I've always thought an interesting experiment would be to first determine an estimated time for a routing update to propagate through the network. Then determine the time required for the Line Up-down Protocol to determine a link is has either just went up or down and then generate the update. Now place a few unscrupulous individuals goegraphically widespread across the network on several interswitch links. Let these individual interupt the link at time T0 and then restore it at T0 + routing propagation time - LUP decision time. How much bandwidth could you forcibly use up with internal routing updates? Ciao, Darrel -------
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Thu, 2-Apr-87 13:22:21 EST From: mfidelma@CC5.BBN.COM.UUCP To: mod.protocols.tcp-ip Subject: ICMP As A Diagnostic Tool?
It's been my observation that ICMP provides some useful functionality for isolating and diagnosing internetwork problems - e.g. by timing pings, looking at what percentage of echos come back, source routing packets via specific paths, route recording, etc. It strikes me that the lack of similar functionality for the OSI world may lead to an OSI internet in which significant classes of problems can not be fault isolated. I find this a rather scary thought. Does anybody have any comments, or better yet, examples of specific internet problems in which ICMP was used for diagnostic purposes? Miles Fidelman BBN Communications mfidelman@bbn.com
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 02 Apr 87 13:22:21 EST (Thu) From: "Miles R. Fidelman" <mfidelma@cc5.bbn.com> To: tcp-ip@sri-nic.ARPA Subject: ICMP As A Diagnostic Tool?
It's been my observation that ICMP provides some useful functionality for isolating and diagnosing internetwork problems - e.g. by timing pings, looking at what percentage of echos come back, source routing packets via specific paths, route recording, etc. It strikes me that the lack of similar functionality for the OSI world may lead to an OSI internet in which significant classes of problems can not be fault isolated. I find this a rather scary thought. Does anybody have any comments, or better yet, examples of specific internet problems in which ICMP was used for diagnostic purposes? Miles Fidelman BBN Communications mfidelman@bbn.com
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Thu, 2-Apr-87 13:33:26 EST From: AFDDN.TCP-IP@GUNTER-ADAM.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Re: Packet network reliability
Paul, On the C/30 algorithm, I believe there are two occurences which can generate an update. One is the expiration of some timer which I've been told is 30 secs. I seem to remember at one time the limit being around 15 secs. The other occurence is in the case where a link is determined to be down. I made the assumption that as the total number of nodes and the connectivity increases then the probability of link problems goes up. Would it increase linearly? Would be an interesting study. I've always thought an interesting experiment would be to first determine an estimated time for a routing update to propagate through the network. Then determine the time required for the Line Up-down Protocol to determine a link is has either just went up or down and then generate the update. Now place a few unscrupulous individuals goegraphically widespread across the network on several interswitch links. Let these individual interupt the link at time T0 and then restore it at T0 + routing propagation time - LUP decision time. How much bandwidth could you forcibly use up with internal routing updates? Ciao, Darrel -------
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Thu, 2-Apr-87 13:45:46 EST From: jkh@VIOLET.BERKELEY.EDU.UUCP To: mod.protocols.tcp-ip Subject: My Broadcast
By now, many of you have heard of (or seen) the broadcast message I sent to
the net two days ago. I have since received 743 messages and have
replied to every one (either with a form letter, or more personally
when questions were asked). The intention behind this effort was to
show that I wasn't interested in doing what I did maliciously or in
hiding out afterwards and avoiding the repercussions. One of the
people who received my message was Dennis Perry, the Inspector General
of the ARPAnet (in the Pentagon), and he wasn't exactly pleased.
(I hear his Interleaf windows got scribbled on)
So now everyone is asking: "Who is this Jordan Hubbard, and why is he on my
screen??"
I will attempt to explain.
I head a small group here at Berkeley called the "Distributed Unix Group".
What that essentially means is that I come up with Unix distribution software
for workstations on campus. Part of this job entails seeing where some of
the novice administrators we're creating will hang themselves, and hopefully
prevent them from doing so. Yesterday, I finally got around to looking
at the "broadcast" group in /etc/netgroup which was set to "(,,)". It
was obvious that this was set up for rwall to use, so I read the documentation
on "netgroup" and "rwall". A section of the netgroup man page said:
...
Any of three fields can be empty, in which case it signifies
a wild card. Thus
universal (,,)
defines a group to which everyone belongs. Field names that ...
...
Now "everyone" here is pretty ambiguous. Reading a bit further down, one
sees discussion on yellow-pages domains and might be led to believe that
"everyone" was everyone in your domain. I know that rwall uses point-to-point
RPC connections, so I didn't feel that this was what they meant, just that
it seemed to be the implication.
Reading the rwall man page turned up nothing about "broadcasts". It doesn't
even specify the communications method used. One might infer that rwall
did indeed use actual broadcast packets.
Failing to find anything that might suggest that rwall would do anything
nasty beyond the bounds of the current domain (or at least up to the IMP),
I tried it. I knew that rwall takes awhile to do its stuff, so I left
it running and went back to my office. I assumed that anyone who got my
message would let me know.. Boy, was I right about that!
After the first few mail messages arrived from Purdue and Utexas, I begin
to understand what was really going on and killed the rwall. I mean, how
often do you expect to run something on your machine and have people
from Wisconsin start getting the results of it on their screens?
All of this has raised some interesting points and problems.
1. Rwall will walk through your entire hosts file and blare at anyone
and everyone if you use the (,,) wildcard group. Whether this is a bug
or a feature, I don't know.
2. Since rwall is an RPC service, and RPC doesn't seem to give a damn
who you are as long as you're root (which is trivial to be, on a work-
station), I have to wonder what other RPC services are open holes. We've
managed to do some interesting, unauthorized, things with the YP service
here at Berkeley, I wonder what the implications of this are.
3. Having a group called "broadcast" in your netgroup file (which is how
it comes from sun) is just begging for some novice admin (or operator
with root) to use it in the mistaken belief that he/she is getting to
all the users. I am really surprised (as are many others) that this has
taken this long to happen.
4. Killing rwall is not going to solve the problem. Any fool can write
rwall, and just about any fool can get root priviledge on a Sun workstation.
It seems that the place to fix the problem is on the receiving ends. The
only other alternative would be to tighten up all the IMP gateways to
forward packets only from "trusted" hosts. I don't like that at all,
from a standpoint of reduced convenience and productivity. Also, since
many places are adding hosts at a phenominal rate (ourselves especially),
it would be hard to keep such a database up to date. Many perfectly well-
behaved people would suffer for the potential sins of a few.
I certainly don't intend to do this again, but I'm very curious as to
what will happen as a result. A lot of people got wall'd, and I would think
that they would be annoyed that their machine would let someone from the
opposite side of the continent do such a thing!
Jordan Hubbard
jkh@violet.berkeley.edu
(ucbvax!jkh)
Computer Facilities & Communications.
U.C. Berkeley
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Thu, 2-Apr-87 13:48:51 EST From: usenet@JADE.BERKELEY.EDU.UUCP To: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip
Path: jade!violet.berkeley.edu!jkh
From: jkh@violet.berkeley.edu (Jordan K. Hubbard)
Newsgroups: mod.protocols.tcp-ip
Subject: jkh annoys the net
Message-ID: <3011@jade.BERKELEY.EDU>
Date: 2 Apr 87 18:48:50 GMT
Sender: usenet@jade.BERKELEY.EDU
Reply-To: jkh@violet.berkeley.edu(Jordan K. Hubbard)
Organization: University of California, Berkeley
Lines: 95
By now, many of you have heard of (or seen) the broadcast message I sent to
the net two days ago. I have since received 743 messages and have
replied to every one (either with a form letter, or more personally
when questions were asked). The intention behind this effort was to
show that I wasn't interested in doing what I did maliciously or in
hiding out afterwards and avoiding the repercussions. One of the
people who received my message was Dennis Perry, the Inspector General
of the ARPAnet (in the Pentagon), and he wasn't exactly pleased.
(I hear his Interleaf windows got scribbled on)
So now everyone is asking: "Who is this Jordan Hubbard, and why is he on my
screen??"
I will attempt to explain.
I head a small group here at Berkeley called the "Distributed Unix Group".
What that essentially means is that I come up with Unix distribution software
for workstations on campus. Part of this job entails seeing where some of
the novice administrators we're creating will hang themselves, and hopefully
prevent them from doing so. Yesterday, I finally got around to looking
at the "broadcast" group in /etc/netgroup which was set to "(,,)". It
was obvious that this was set up for rwall to use, so I read the documentation
on "netgroup" and "rwall". A section of the netgroup man page said:
...
Any of three fields can be empty, in which case it signifies
a wild card. Thus
universal (,,)
defines a group to which everyone belongs. Field names that ...
...
Now "everyone" here is pretty ambiguous. Reading a bit further down, one
sees discussion on yellow-pages domains and might be led to believe that
"everyone" was everyone in your domain. I know that rwall uses point-to-point
RPC connections, so I didn't feel that this was what they meant, just that
it seemed to be the implication.
Reading the rwall man page turned up nothing about "broadcasts". It doesn't
even specify the communications method used. One might infer that rwall
did indeed use actual broadcast packets.
Failing to find anything that might suggest that rwall would do anything
nasty beyond the bounds of the current domain (or at least up to the IMP),
I tried it. I knew that rwall takes awhile to do its stuff, so I left
it running and went back to my office. I assumed that anyone who got my
message would let me know.. Boy, was I right about that!
After the first few mail messages arrived from Purdue and Utexas, I begin
to understand what was really going on and killed the rwall. I mean, how
often do you expect to run something on your machine and have people
from Wisconsin start getting the results of it on their screens?
All of this has raised some interesting points and problems.
1. Rwall will walk through your entire hosts file and blare at anyone
and everyone if you use the (,,) wildcard group. Whether this is a bug
or a feature, I don't know.
2. Since rwall is an RPC service, and RPC doesn't seem to give a damn
who you are as long as you're root (which is trivial to be, on a work-
station), I have to wonder what other RPC services are open holes. We've
managed to do some interesting, unauthorized, things with the YP service
here at Berkeley, I wonder what the implications of this are.
3. Having a group called "broadcast" in your netgroup file (which is how
it comes from sun) is just begging for some novice admin (or operator
with root) to use it in the mistaken belief that he/she is getting to
all the users. I am really surprised (as are many others) that this has
taken this long to happen.
4. Killing rwall is not going to solve the problem. Any fool can write
rwall, and just about any fool can get root priviledge on a Sun workstation.
It seems that the place to fix the problem is on the receiving ends. The
only other alternative would be to tighten up all the IMP gateways to
forward packets only from "trusted" hosts. I don't like that at all,
from a standpoint of reduced convenience and productivity. Also, since
many places are adding hosts at a phenominal rate (ourselves especially),
it would be hard to keep such a database up to date. Many perfectly well-
behaved people would suffer for the potential sins of a few.
I certainly don't intend to do this again, but I'm very curious as to
what will happen as a result. A lot of people got wall'd, and I would think
that they would be annoyed that their machine would let someone from the
opposite side of the continent do such a thing!
Jordan Hubbard
jkh@violet.berkeley.edu
(ucbvax!jkh)
Computer Facilities & Communications.
U.C. Berkeley
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Thu, 2-Apr-87 14:02:36 EST From: GROSSMAN@SIERRA.STANFORD.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: danger of bridges
In the absence of a Designated Router, DECnet endnodes (on an Ethernet) will attempt to communicate by sending to the destination node's Ethernet address. This Ethernet address is computed from the node's DECnet host number. This is why all DECnet hosts on an Ethernet have funny addresses. A DECnet Ethernet address looks like AA-00-04-00-XX-YY, where XX-YY is the DECnet host number with the bytes swapped (don't shoot me, I'm just the piano player). Stu Grossman -------
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: Thu, 2-Apr-87 15:19:00 EST From: bill@NRL-LCP.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Re: Response to anti-bridge comments
> Date: Tue, 31 Mar 87 15:33:29 EST > From: jas@monk.proteon.com (John A. Shriver) > Subject: Response to anti-bridge comments > The very nature of bridges prevents you from doing load > sharing (unless you manually program the filtering/forwarding > databases, giving up the advantages of adaptive bridges). I don't think it's anything intrinsic about a Bridge that would prevent you from doing load sharing. It's only a function of the current Bridge software that this isn't currently possible. One simple scheme that I just happened to think of off the top of my head would involve having 2**N Bridges numbered from 0 to 2**N-1, and each Bridge would handle those Ethernet addresses which modulo 2**N matched its own assigned Bridge number. A hot spare could detect the failure of any particular live Bridge, and take over for it. One Bridge could be designated to handle broadcast packets. Does anyone know if such a scheme or anything similar has been considered for doing load sharing across Bridges? It doesn't seem that it would be that difficult to implement. By the way, in practice, at least at our site, the level of traffic through our Ethernet Bridges is nowhere near significant enough to even start to worry about load sharing, and we have a fairly extensive Ethernet based network in active use here at NRL. > Gateways > with multipath internal routing algorithms can do load sharing, look > at BBN's PSN software using SPF on the ARPANET and MILNET. Sooner or > later, a network gets big enough and complicated enough that one > migrates from bridges to routers. Although Gateways/Routers COULD also do load sharing with appropriate routing algorithms, it is my understanding that all of the current Gateways, even those with SPF routing, DO NOT currently do any kind of load sharing, and only understand and compute a single path to any given destination. I specifically asked this question at the TCP/IP Interoperability Conference held just recently in Monterey, and that was the answer I was given by someone involved with the SPF routing Gateways. > What the advocates are arguing about is where the line between bridges > and routers is. I think there are appropriate circumstances to use both Bridges and Gateways/Routers. The primary benefits that I see for using Bridges, given the state of current technology, is ease of installation, monitoring, and management, and the fact that they are protocol transparent to the higher layer protocols. In the future, they will probably even be used to connect dissimilar technologies, such as Ethernet and FDDI Fiber Optic networks. But Gateways certainly have their appropriate niche also, such as providing a higher degree of isolation between the connected networks when this is desirable. -My first plunge -Bill Fink bill@NRL-LCP ------
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 2 Apr 87 15:19:00 EST From: <bill@nrl-lcp.arpa> To: "tcp-ip" <tcp-ip@nic> Subject: Re: Response to anti-bridge comments
> Date: Tue, 31 Mar 87 15:33:29 EST > From: jas@monk.proteon.com (John A. Shriver) > Subject: Response to anti-bridge comments > The very nature of bridges prevents you from doing load > sharing (unless you manually program the filtering/forwarding > databases, giving up the advantages of adaptive bridges). I don't think it's anything intrinsic about a Bridge that would prevent you from doing load sharing. It's only a function of the current Bridge software that this isn't currently possible. One simple scheme that I just happened to think of off the top of my head would involve having 2**N Bridges numbered from 0 to 2**N-1, and each Bridge would handle those Ethernet addresses which modulo 2**N matched its own assigned Bridge number. A hot spare could detect the failure of any particular live Bridge, and take over for it. One Bridge could be designated to handle broadcast packets. Does anyone know if such a scheme or anything similar has been considered for doing load sharing across Bridges? It doesn't seem that it would be that difficult to implement. By the way, in practice, at least at our site, the level of traffic through our Ethernet Bridges is nowhere near significant enough to even start to worry about load sharing, and we have a fairly extensive Ethernet based network in active use here at NRL. > Gateways > with multipath internal routing algorithms can do load sharing, look > at BBN's PSN software using SPF on the ARPANET and MILNET. Sooner or > later, a network gets big enough and complicated enough that one > migrates from bridges to routers. Although Gateways/Routers COULD also do load sharing with appropriate routing algorithms, it is my understanding that all of the current Gateways, even those with SPF routing, DO NOT currently do any kind of load sharing, and only understand and compute a single path to any given destination. I specifically asked this question at the TCP/IP Interoperability Conference held just recently in Monterey, and that was the answer I was given by someone involved with the SPF routing Gateways. > What the advocates are arguing about is where the line between bridges > and routers is. I think there are appropriate circumstances to use both Bridges and Gateways/Routers. The primary benefits that I see for using Bridges, given the state of current technology, is ease of installation, monitoring, and management, and the fact that they are protocol transparent to the higher layer protocols. In the future, they will probably even be used to connect dissimilar technologies, such as Ethernet and FDDI Fiber Optic networks. But Gateways certainly have their appropriate niche also, such as providing a higher degree of isolation between the connected networks when this is desirable. -My first plunge -Bill Fink bill@NRL-LCP ------
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: Thu, 2-Apr-87 18:20:00 EST From: CERF@A.ISI.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: ICMP As A Diagnostic Tool?
I "pinger and grease monkey of the year" award probably goes to DAve Mills who has probably launched more pings in the Internet than any other player. Vint
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 2 Apr 1987 18:20-EST From: CERF@A.ISI.EDU To: mfidelma@CC5.BBN.COM Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: ICMP As A Diagnostic Tool?
I "pinger and grease monkey of the year" award probably goes to DAve Mills who has probably launched more pings in the Internet than any other player. Vint
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: Thu, 2-Apr-87 21:01:33 EST From: BOB@WARD.CS.WASHINGTON.EDU.UUCP To: mod.protocols.tcp-ip Subject: ip subnets
I am trying to gather a bit of information about the use of subnets on the internet. Of all the sites on the internet that have been assigned a class-B (class-A too, but there are not many of those) network number, who uses subnets. If you have a class-B network number, I would like to ask you 2 questions: 1) Do you use subnets? Why? 2) What type of link/physical layers do you run ip datagrams over? Any responses would be greatly appreciated. I will tabulate and post to the net, if there is sufficient interest. -thanks. -bob -------
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Thu, 2-Apr-87 21:45:55 EST From: narten@PURDUE.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Tcp/Ip vs a store & forward network
> Presumably, as domain names get extended, we will be able to > do that. Any mail you send to a user can go directly to the machine > where the his/her mailbox resides. No forwarding at the site would be > needed. There is still a hole with current TCP mailers in that often mail really travels an extra hop. That is, mail for janedoe@somewhere.edu gets sent to the machine at "somewhere.edu", which after accepting the mail, turns around and forwards it the machine the user reads mail on. I would prefer an acknowledgement that mail has actually been placed in the users mailbox, rather than just handing the mail to a "reliable" delivering agent at the site. Domain names were designed to handle lots more than just machine name to IP address mappings. At some point, it will (hopefully) be possible to register mailboxes in the system. That way, mail sent to janedoe@somewhere.edu will not necessarily mean sending the mail to "somewhere.edu". Rather, sendmail will find the real agent via nameserver queries about "janedoe@somewhere.edu". Now mail gets sent directly to the machine where the user's mailbox resides, and now when the mail is no longer in the sender's local queue, it really is in the correct mailbox, and not still in transit somewhere. Thomas
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: Thu, 02 Apr 87 14:57:04 O From: Henry Nussbacher <HANK%BARILVM.BITNET@wiscvm.wisc.edu> To: tcp-ip@sri-nic.ARPA Subject: Bitnet protocols
I sent this yesterday and I never saw it come back so I have a feeling it got lost on its way: (Caveat - This description is primarily for people who have no idea how Bitnet works.) Greg, The concept of remote access doesn't exist in Bitnet. The protocols in Bitnet are as follows: 1) One-way File Transfer - any user is allowed to send a file to any other user. Since the file ends up in the destination users spool system (or some emulation thereof) there is no problem with access control. 2) Interactive Message - any user can send a one line message (max 160 characters) to any other user. All you need to know is the destination user and node. If the user is not logged on or a link is down you are told so. Based on these two primitives - Bitnet has built various other pseudo-protocols. From #1 above - we are able to do mail, list explosion, computer conferencing, general file transfer. From #2 above, Bitnet has developed a CB (Chat) system. By combined both of the basic primitives above, a file server can be set up at any node that will trap incoming 'Interactive Messages' - which contain a command and process the command and send the results back to the user via the 'One-Way File Transfer' mechanism. This method allows users to sit at their machine and issue commands like DIR or LIST to some remote file server and then issue some SEND commands to retrieve the files they want. There is no need in that case to do any sort of remote connect (anonymous FTP). Most servers (200+) in Bitnet also accept transactions via files or RFC822 mail. Lately, various servers in Arpanet have decided that is also a 'clever' thing to have, so we have things like archive-request@simtel20.arpa and service@sri-nic.arpa popping up (I expect more before the end of th year). So to answer your question: > a remote file they own They cannot access it. Yup would be nice and that is just one reason why Bitnet should convert to Tcp/Ip. Incidentally, there is a program I distribute in Bitnet that allows this remote access to a file the person owns but it is a private convention. The program runs as a task (and therefore must be running when the remote user wants access to his/her files). and the user needs to set up a remote access password. It uses the Interactive Message Primitive to send and receive data, and each command you want executed on the remote host must be prefixed with your remote pswd. Not as elegent as TELNET but when the entire concept of TELNET doesn't exist it is the best one can do. > a remote file they don't own, but is not protected Only if the file is available via a remote file server can they access it. > a remote file they don't own, but is protected They can't access it. Hope this helps. Hank
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Fri, 3-Apr-87 02:14:34 EST From: Mills@UDEL.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: danger of bridges
Drew, The fuzzies, as you know, use broadcast, rather than multicast. There is in principle no problem using restricted multicast, but then this also apllies to RIP and others. Do you have a concrete suggestion on how to manage the multicast group? Dave
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: Fri, 3-Apr-87 02:17:47 EST From: Mills@UDEL.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: INFO REQUEST!
Brian, Contact Dave Stoffel (dave@mimsy.umd.edu) for much information on Braille and computers, including packet radio and related topics. Dave
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Fri, 3-Apr-87 05:35:23 EST From: jon@CS.UCL.AC.UK.UUCP To: mod.protocols.tcp-ip Subject: NIFTP
A few days ago i inadvertantly mentioned the UK JNT spooled file transfer service as a neat means of getting data around a network. A larginsh number of people have asked me for more information, so Network Independant File Transfer protocol (aka Blue Book), normally runs over transport + X.25, but can and does run over TCP/IP at some sites (using well known port 47). Does recovery from connection failure, is spooled etc. Is widely used in the UK for email, a lot. A list of implementations can be got from: r.cooper@gec-b.rutherford.ac.uk One unix version can be got from SApider Systems, or ask piet brooks at Cambridge (don't have his address, but requests to mailgroup@ucl.cs.ac.uk will find him). jon
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Fri, 3-Apr-87 07:46:44 EST From: sra@MITRE-BEDFORD.ARPA.UUCP To: mod.protocols.tcp-ip Subject: TCP/IP for NCR 3000, Burrougs XE520 and B-25
The ULANA program has been requested to add three machines to its list of hosts to be supported. These are: NCR WS3000 with CTOS Burroughs XE520 with CTOS, BTOS, MSDOS, or XENIX Burroughs B-25 with MSDOS, or BTOS I am unfamilar with any of these machines but I would like to acomodiate the request if interfaces are available. We are looking for an 802.3 interface with TCP,IP,TELNET,FTP,SMPT,etc any information or leads would be greatly appreciated. Stan Ames sra at mitre-bedford
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Fri, 3-Apr-87 10:28:41 EST From: mohamed%hscfvax@HARVARD.HARVARD.EDU.UUCP To: mod.protocols.tcp-ip Subject: Time RFC 868
I would like to hear from sites that keep exact time and make it available (RFC 868) to others. Also whether it is available via TCP or UDP. Thanks ellozy@harvard.harvard.edu
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: Fri, 3 Apr 87 10:28:41 EST From: mohamed%hscfvax@harvard.harvard.edu (750025@Mohamed_el_Lozy) To: tcp-ip@sri-nic.arpa Subject: Time RFC 868
I would like to hear from sites that keep exact time and make it available (RFC 868) to others. Also whether it is available via TCP or UDP. Thanks ellozy@harvard.harvard.edu
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: Fri, 3-Apr-87 10:29:37 EST From: jmg@CERNVAX.BITNET.UUCP To: mod.protocols.tcp-ip Subject: Ethernet TCP/IP broadcasts: help
Last Wednesday (yes, it was April 1st; no it was NO JOKE) we got a situation on our Ethernet where a particular telnet RST packet from a host to a client was being sent inside a broadcast packet. The trouble was that this same broadcast packet was being sent out repeatedly by just about every TCP/IP host on our Ethernet (including both VMS with Wollongong and 4.2BSD). Thus, we were seeing about 1000 broadcast packets per second, coming from many diffferent sources but all containing this same RST information. This was, of course, killing all the small microvaxes and weaker 750/780 etc., with only the big 8800 having enough clout to continue apparently normally. We eventually stopped it by disconnecting all of the offenders, much to their disgust. After that everything started fine. Since we started installing Ethernet some years ago we have never seen such a catastrophic situation. Therefore, if anyone has any idea why so many vaxes should start rebroadcasting packets which were nothing to do with them I should be eternally grateful. Mike Gerard
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Fri, 3-Apr-87 11:52:45 EST From: brescia@CCV.BBN.COM.UUCP To: mod.protocols.tcp-ip Subject: multicast groups on ether (was: danger of bridges)
Do you have a concrete suggestion on how to manage the multicast group?
How about the following (summary: manage by czar).
The goal is to completely eliminate use of the broadcast address. TCP/IP
implementations may be overusing this feature, between ARP, RWHO, etc.
Go to the ethernet number czar and get two (2) groups of 65536 (2^^16)
multicast addresses. By that, I mean the high order 32 bits are assigned by
the czar, and the low 16 bits are ours to play with. Call the first group
<ether-link> and the second group <ip-port>. These become well know, and wired
in the programs, much like 255.255.255.255.255.255 is today.
The first group, <ether-link>, is the contact address for all hosts which
handle 'broadcast' for a particular ether link (message type). Thus ARP,
instead of polluting all the hosts in the net, would send to the address
<ether-link>.8.6 (0x0806 is the number assigned to the address resolution
protocol).
The second group, <ip-port> is the set of addresses for IP broadcast
protocols, and subdivided into one byte of IP protocol (e.g. UDP, 17), and one
byte of well-known-port (e.g. RWHO, 550 (oops, well, you get the idea).
While this idea is a bit half-baked, it should serve to move host and gateway
impementations to independence from broadcasts.
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: 03 Apr 87 11:52:45 EST (Fri) From: Mike Brescia <brescia@ccv.bbn.com> To: Mills@louie.udel.edu Cc: Drew Daniel Perkins <ddp#@andrew.cmu.edu>, tcp-ip@sri-nic.ARPA, tsuchiya@gateway.mitre.org, x3s33-interest@gateway.mitre.org Subject: multicast groups on ether (was: danger of bridges)
Do you have a concrete suggestion on how to manage the multicast group?
How about the following (summary: manage by czar).
The goal is to completely eliminate use of the broadcast address. TCP/IP
implementations may be overusing this feature, between ARP, RWHO, etc.
Go to the ethernet number czar and get two (2) groups of 65536 (2^^16)
multicast addresses. By that, I mean the high order 32 bits are assigned by
the czar, and the low 16 bits are ours to play with. Call the first group
<ether-link> and the second group <ip-port>. These become well know, and wired
in the programs, much like 255.255.255.255.255.255 is today.
The first group, <ether-link>, is the contact address for all hosts which
handle 'broadcast' for a particular ether link (message type). Thus ARP,
instead of polluting all the hosts in the net, would send to the address
<ether-link>.8.6 (0x0806 is the number assigned to the address resolution
protocol).
The second group, <ip-port> is the set of addresses for IP broadcast
protocols, and subdivided into one byte of IP protocol (e.g. UDP, 17), and one
byte of well-known-port (e.g. RWHO, 550 (oops, well, you get the idea).
While this idea is a bit half-baked, it should serve to move host and gateway
impementations to independence from broadcasts.
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: Fri, 3 Apr 87 12:14:24 EST From: Mills@UDEL.EDU To: jon@cs.ucl.ac.uk Cc: tcp-ip@sri-nic.arpa Subject: Re: Tcp/Ip vs a store & forward network
Jon, Then your worries are over. There is a NIFTP implementation running on TOPS-20s and fuzzballs. Since further development of FTP is not in the mainstream and that dinosaur is many years old now, it is not fair to bash it. Why don't you guys poke Berkeley to include your NIFTP with Unix distributions as an interim until FTAM (on TCP or whatever) is available? Dave
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 1987 15:55-PST From: Steve Deering <deering@pescadero.stanford.edu> To: Mike Brescia <brescia@ccv.bbn.com> Cc: Mills@louie.udel.edu, Drew Daniel Perkins <ddp@andrew.cmu.edu>, tcp-ip@sri-nic.ARPA, tsuchiya@mitre-gateway.ARPA, x3s33-interest@mitre-gateway.ARPA Subject: Re: multicast groups on ether
The goal is to completely eliminate use of the broadcast address. TCP/IP
implementations may be overusing this feature, between ARP, RWHO, etc.
Hear! hear! At the moment, if you want to use IP on an Ethernet, you
must listen to Ethernet broadcasts, for the sake of ARP. Here at
Stanford, that means you get to receive and discard packets broadcast
for RWho, Reverse ARP, RIP, TFTP, Time, Domain Name lookups, Pup name
lookups, BOOTP, ND, Pup routing, XNS routing,... and whatever new
broadcast protocol was invented today.
In RFC988, I propose a way to manage multicast addresses for IP-based
applications. I suggest that the number czar should allocate well-known
IP multicast address, rather than Ethernet multicast addresses, and that
there should be a standard mapping from IP to local network multicast
addresses for each type of local network.
As for ARP, I think ARP-for-IP should use a different Ethernet multicast
address than ARP-for-Chaos or ARP-for-whatever, even though they use the
same Ether-type. And, of course, Reverse ARP should use different
addresses than ARP.
To phase in multicast-based ARP, you could (during the phase-in period)
listen to both the broadcast address and the multicast address. When
sending an ARP request, use the multicast address first, then broadcast
if you don't get a reply.
Karen Lam of BBN has extended the 4.3bsd UNIX IP code to support
RFC988-style multicasting, on top of which I have implemented a
multicast version of Berkeley's rwho daemon. This code (both Karen's
and mine) is running successfully at a couple of test sites and I hope
it will soon be made available for wider distribution to those who wish
to experiment with IP multicasting.
I would appreciate any feedback on RFC988. I would also like to hear
of any other work going on in the area of internetwork multicasting.
In particular, is the x3s33 committee considering internetwork multicast
addressing and routing?
Steve Deering
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Fri, 3-Apr-87 13:45:11 EST From: gds@SPAM.ISTC.SRI.COM.UUCP To: mod.protocols.tcp-ip Subject: Re: Tcp/Ip vs a store & forward network
There is still a hole with current TCP mailers in that often mail
really travels an extra hop. That is, mail for janedoe@somewhere.edu
gets sent to the machine at "somewhere.edu", which after accepting the
mail, turns around and forwards it the machine the user reads mail on.
I would prefer an acknowledgement that mail has actually been placed
in the users mailbox, rather than just handing the mail to a
"reliable" delivering agent at the site.
Like the gentleman from rice said, you don't always know when mail is
placed in the user's mailbox. It may be a post-office type system,
where mail is read from a mail server, but composed from the mail
client. Everything is done without forwarding. When do you decide that
the mail is in the mailbox?
Domain names were designed to handle lots more than just machine name
to IP address mappings. At some point, it will (hopefully) be possible
to register mailboxes in the system. That way, mail sent to
janedoe@somewhere.edu will not necessarily mean sending the mail to
"somewhere.edu". Rather, sendmail will find the real agent via
nameserver queries about "janedoe@somewhere.edu". Now mail gets sent
directly to the machine where the user's mailbox resides, and now when
the mail is no longer in the sender's local queue, it really is in the
correct mailbox, and not still in transit somewhere.
It still might be in transit somewhere -- the mailbox entries may point
to non-Internet sites which will require at least an extra hop at a mail
bridge.
Does this "ack" scheme imply retransmission of a mail message until a
retransmission timeout? I would hate to see those old "Message queued
for 3 days -- will try again for another 12 days" messages from mailers
coming to my mailbox again.
--gregbo
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Fri, 03 Apr 87 10:18:05 +0000 From: Jon Crowcroft <jon@Cs.Ucl.AC.UK> To: tcp-ip@sri-nic.arpa Subject: NIFTP
A few days ago i inadvertantly mentioned the UK JNT spooled file transfer service as a neat means of getting data around a network. A larginsh number of people have asked me for more information, so Network Independant File Transfer protocol (aka Blue Book), normally runs over transport + X.25, but can and does run over TCP/IP at some sites (using well known port 47). Does recovery from connection failure, is spooled etc. Is widely used in the UK for email, a lot. A list of implementations can be got from: r.cooper@gec-b.rutherford.ac.uk One unix version can be got from SApider Systems, or ask piet brooks at Cambridge (don't have his address, but requests to mailgroup@ucl.cs.ac.uk will find him). jon
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: Fri, 3-Apr-87 15:29:31 EST From: m15368%mwvm@MITRE.ARPA.UUCP To: mod.protocols.tcp-ip Subject: (none)
To: CERF%A.ISI.EDU CERF at A.ISI.EDU
From: Steve Silverman
Subject: Layer 2 multiplexing on ISDN
The proposed Frame Relay service of ISDN does do layer 2 multiplexing.
In LAPD, there is a 2 byte address containing a 6 bit SAPI and a 7 bit TEI
(Terminal Equipment Identifier). These 2 fields are combined into a
13 bit DLCI (Data Link Connection Identifier) which would be handled
similarly to the LCN in X.25. It would be mapped and set in each node as a
frame progressed through the network. Then a new CRC would be calculated
and inserted.
*
* Steve
Cc: TCP-IP@SRI-NIC.ARPA MITRE(MCKEE) MCKEE at MITRE
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Fri, 3-Apr-87 17:25:06 EST From: martinea@SKL-CRC.ARPA.UUCP To: mod.protocols.tcp-ip Subject: RDP source
Is anyone aware of public domain RDP source??? I would like to use RDP but want to avoid the pain of re-inventing the wheel. Thanks in advance. Mike Martineau
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Fri, 3-Apr-87 18:55:00 EST From: deering@PESCADERO.STANFORD.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: multicast groups on ether
The goal is to completely eliminate use of the broadcast address. TCP/IP
implementations may be overusing this feature, between ARP, RWHO, etc.
Hear! hear! At the moment, if you want to use IP on an Ethernet, you
must listen to Ethernet broadcasts, for the sake of ARP. Here at
Stanford, that means you get to receive and discard packets broadcast
for RWho, Reverse ARP, RIP, TFTP, Time, Domain Name lookups, Pup name
lookups, BOOTP, ND, Pup routing, XNS routing,... and whatever new
broadcast protocol was invented today.
In RFC988, I propose a way to manage multicast addresses for IP-based
applications. I suggest that the number czar should allocate well-known
IP multicast address, rather than Ethernet multicast addresses, and that
there should be a standard mapping from IP to local network multicast
addresses for each type of local network.
As for ARP, I think ARP-for-IP should use a different Ethernet multicast
address than ARP-for-Chaos or ARP-for-whatever, even though they use the
same Ether-type. And, of course, Reverse ARP should use different
addresses than ARP.
To phase in multicast-based ARP, you could (during the phase-in period)
listen to both the broadcast address and the multicast address. When
sending an ARP request, use the multicast address first, then broadcast
if you don't get a reply.
Karen Lam of BBN has extended the 4.3bsd UNIX IP code to support
RFC988-style multicasting, on top of which I have implemented a
multicast version of Berkeley's rwho daemon. This code (both Karen's
and mine) is running successfully at a couple of test sites and I hope
it will soon be made available for wider distribution to those who wish
to experiment with IP multicasting.
I would appreciate any feedback on RFC988. I would also like to hear
of any other work going on in the area of internetwork multicasting.
In particular, is the x3s33 committee considering internetwork multicast
addressing and routing?
Steve Deering
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Fri, 3-Apr-87 21:18:43 EST From: LYNCH@A.ISI.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: My Broadcast
John, I think you did a good thing. Testing for idiotic holes in the "system". Now, if you could figure out a way to encourage them to get plugged. I remember years ago being annoyed at the loose security in the Tenex operating system that was prevalent on the early Arpanet. I couldn't get the wizards at BBN to "fix" the problems by the "usual" means. So, one day I took advantage of the holes and, across the net, all by myself with no confederates, obtained the password of the wizard of all wizards and sent it to him in a one word mail message. No other communication was necessary. He plugged the holes as fast as his fingers could type. I was a "good guy" and he knew it, but it took an actual event to drive the point home it wouldn't be too long before someone else would figure out the method i used an dperhaps not be so benign. Can you think of a similar thing to do? Or have you already done it? (I think not because what you are pointing out is going to take lots of thinking to solve. But, it has to start somewhere. Dan -------
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 1987 21:18:43 EST From: Dan Lynch <LYNCH@A.ISI.EDU> To: jkh%violet.Berkeley.EDU@UCBVAX.BERKELEY.EDU (Jordan K. Hubbard) Cc: hackers_guild@UCBVAX.BERKELEY.EDU, tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU Subject: Re: My Broadcast
John, I think you did a good thing. Testing for idiotic holes in the "system". Now, if you could figure out a way to encourage them to get plugged. I remember years ago being annoyed at the loose security in the Tenex operating system that was prevalent on the early Arpanet. I couldn't get the wizards at BBN to "fix" the problems by the "usual" means. So, one day I took advantage of the holes and, across the net, all by myself with no confederates, obtained the password of the wizard of all wizards and sent it to him in a one word mail message. No other communication was necessary. He plugged the holes as fast as his fingers could type. I was a "good guy" and he knew it, but it took an actual event to drive the point home it wouldn't be too long before someone else would figure out the method i used an dperhaps not be so benign. Can you think of a similar thing to do? Or have you already done it? (I think not because what you are pointing out is going to take lots of thinking to solve. But, it has to start somewhere. Dan -------
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: Fri, 3-Apr-87 21:40:49 EST From: Mills@UDEL.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: IP over x.25
Gerd, I assume the X.25 connection is broken somewhere in the public-net path, perhaps in either of the national X.25 nets or in the X.75 gateway(s). To break that after two minutes of inactivity sounds broken in the extremus, especially if the restoration costs real Geld. On the other hand, your opens are cheap, about equivalent to twenty seconds of connect time, so maybe things aren't that bad, at least if the reset/open can be made transparent to your TCP/TELNET connection. Come to think of it, if the MILNET/ARPANET congestions is as fierce as you report, it might be cheaper to encapsulate IP datagrams as fast-select packets, rather than go through the complete virtual-circuit clankery. This might be a fun puddle to go wading in. Lemme see, at twenty (roundtrip!) packets per Mark, you would break even at about seven minutes. Maybe not too bad under current conditions... While it is in principle possible to do all kinds of things which might convey the connection-closed state at the VAN gateway to the end systems, I suggest this would not be very useful if only to stimulate a re-open. If it really does come down to keeping the connection open, the VAN driver could be modified to send ICMP echoes to its peer just often enough to reset the VAN timers. Be advised you did not hear me say this, for I am not present and will instantly disavow any attribution of such nonsense to mine lips. Now, I hope that will keep the truthspeakers from my throat. Yes, and stop the ICMP echoes after a period when no other traffic is present. [Gaggg] Dave
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Fri, 3-Apr-87 22:48:51 EST From: gordan@maccs.UUCP.UUCP To: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip
Path: maccs!gordan
From: gordan@maccs.UUCP (Gordan Palameta)
Newsgroups: mod.protocols.tcp-ip
Subject: TCP retransmission
Keywords: retransmission algorithm
Message-ID: <519@maccs.UUCP>
Date: 4 Apr 87 03:48:50 GMT
Reply-To: gordan@maccs.UUCP (Gordan Palameta)
Distribution: world
Organization: DCSS, McMaster University, Hamilton, Ontario, Canada
Lines: 20
Hello...
I'm currently writing some TCP-IP code (for a PDP-11 running RT-11), and am
looking to do retransmissions correctly.
From what I've read here, poor retransmission behavior is a major source
of congestion... although my code is intended for a very lightly loaded
Ethernet and I can get away with being sloppy, if there's a painless way to
do it right for the general case, it would be nice to put it in.
I understand the idea of exponential backoff, and know of the RTT-based
algorithm suggested in the RFC (which I believe is what BSD 4.2 uses (?))...
is this the proper algorithm to use, or is there a better one?
Thanks for any info...
--
UUCP: ... !seismo!mnetor!lsuc!maccs!gordan (note ..dAn or mail may bounce)
BITNET: GP@TANDEM ^ <---'
Gordan Palameta
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: Fri, 3-Apr-87 23:18:26 EST From: cyrus@hi.UUCP.UUCP To: mod.protocols.tcp-ip Subject: Re: Ethernet TCP/IP broadcasts: help
In article <459@cernvax.UUCP> cernvax!jmg () writes:
>
>Last Wednesday (yes, it was April 1st; no it was NO JOKE) we got a
>situation on our Ethernet where a particular telnet RST packet from
>a host to a client was being sent inside a broadcast packet. The
>trouble was that this same broadcast packet was being sent out repeatedly
>by just about every TCP/IP host on our Ethernet (including both VMS
>with Wollongong and 4.2BSD). Thus, we were seeing about 1000 broadcast
>packets per second, coming from many diffferent sources but all containing
>this same RST information. This was, of course, killing all the small
>microvaxes and weaker 750/780 etc., with only the big 8800 having enough
>clout to continue apparently normally.
>
>We eventually stopped it by disconnecting all of the offenders, much
>to their disgust. After that everything started fine.
>
>Since we started installing Ethernet some years ago we have never seen
>such a catastrophic situation. Therefore, if anyone has any idea why
>so many vaxes should start rebroadcasting packets which were nothing
>to do with them I should be eternally grateful.
>
>Mike Gerard
We had a simular problem with one of our micro vax II running Ultrix.
There had been a brown out (power surge) and all our machines continued
to run (more uvax II's and sun 2's and 3's). We noticed that the network
was slow though. After some investigation we determined that this one
uvax II was rebroadcasting every packet on the network 4, yes four times.
We tried 'ifconfig down' and then 'ifconfig up' without any success.
The only thing we could do was to reboot.
A possible explanation was that the dequna's table of valid ethernet
addresses to accept got hosed. If this occured then it would basically
be like in promiscuous mode. On receiving these packets it would determine
that none of the packets were for it so it would REbroadcast these packets.
This still does not explain why it was duplicating packets.
Strange............
Sorry this is no help but, ....
--
@__________@ W. Tait Cyrus (505) 277-0806
/| /| University of New Mexico
/ | / | Dept of EECE - Hypercube Project
@__|_______@ | Albuquerque, New Mexico 87131
| | | |
| | hc | | e-mail:
| @.......|..@ cyrus@hc.dspo.gov or cyrus@hc.arpa or
| / | / {gatech|ucbvax|convex}!unmvax!hi!cyrus
@/_________@/
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Sat, 04 Apr 87 10:40:32 EST From: H. Craig McKee <mckee@mitre.ARPA> To: CERF@A.ISI.EDU Cc: mckee@mitre.ARPA, tcp-ip@SRI-NIC.ARPA, m15368%mwvm@mitre.ARPA Subject: Layer 2 muxing on ISDN
The proposed Frame Relay service of ISDN does do layer 2 multiplexing.
In LAPD, there is a 2 byte address containing a 6 bit SAPI and a 7 bit TEI
(Terminal Equipment Identifier). These 2 fields are combined into a
13 bit DLCI (Data Link Connection Identifier) which would be handled
similarly to the LCN in X.25. It would be mapped and set in each node as a
frame progressed through the network. Then a new CRC would be calculated
and inserted.
*
* Steve
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: Sat, 4-Apr-87 12:04:27 EST From: mckee@MITRE.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Re: overloaded station wagon
>Forgive my inexperience at these things.
>I was just under the impression
>that such conversations are usually carried on elsewhere.
>I am being forced to filter my mail,
>to distill other more useful information on TCP/IP.
Come on, friend, lighten up, we are an eclectic group. If you have no
use for an Illudium Q-2 Explosive Network Demodulator then I offer the
following story concerning the relative skills of French and German
diplomats.
At a banquet celebrating the fiftieth birthday of a reigning Queen,
whose name I will not mention for the sake of tact, every country
contributed a typical dish to the meal. Unfortunately, the frijoles
refritos from Mexico and garbanzos from Spain very soon affected the
delicate digestion of the Queen. In a moment of silence, one could
hear, very definitely from the seat of honor, the sound of escaping air.
Immediately, the French Ambassador, purple-faced, was on his feet
saying, "Madame, I beg you, mille pardons, but my digestive system has
been very labile. I have been warned by my doctor to eat bland foods
but have been unable to resist these delicacies."
This, of course, was a serious diplomatic defeat for the other
ambassadors present, and was particularly felt by the representative of
the Third Reich, one Joachim von Ribbentrop.
With a keen ear, he awaited another such happening from the royal
presence, and when it occurred, he jumped to his feet, clicked his
heels, and bowed, shouting, "Madame, this one and the next three are for
the Third Reich."
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: Sat, 4-Apr-87 15:38:42 EST From: malis@CC5.BBN.COM.UUCP To: mod.protocols.tcp-ip Subject: Re: Packet network reliability
Darrel, I'm afraid your experiment wouldn't cause much as much routing traffic as you think. Your details on the PSN routing algorithm were a bit wrong. First, there are three things that can cause a routing update to be generated: a link going up or down, the delay to a neighbor PSN changing more than a certain threshold, or the expiration of 50 seconds from the last time the PSN generated an update. Second, a PSN can generate an update at most every 10 seconds, no matter how much is changing in the network. Third, when a link goes down, it takes 60 seconds to bring it back up (this ensures that if a PSN was isolated from the network, it cannot bring up its links until it has received at least one routing update from every other PSN in the network; otherwise, its routing database would be incomplete). The estimated time for a routing update to propagate through the network is simply the network "diameter" (the minimum-hop path between the two most logically distant PSNs in the network) times the average propagation delay across the links. Flooding routing updates gets the highest priority in the PSN, so intra-PSN delays are usually negligible. Since routing updates cannot be generated at a greater rate than every 10 seconds by each PSN and at least every 50 seconds, it is easy to calculate the minimum, average, and maximum number of routing updates per minute on a network. And since the line up/down protocol keeps links down for at least 60 seconds, manually making links go up or down will probably not produce any more updates than you would have had anyway. Andy
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: 04 Apr 87 15:38:42 EST (Sat) From: Andy Malis <malis@cc5.bbn.com> To: AFDDN.TCP-IP@gunter-adam.ARPA Cc: tsuchiya@gateway.mitre.org, tcp-ip@sri-nic.ARPA, malis@cc5.bbn.com Subject: Re: Packet network reliability
Darrel, I'm afraid your experiment wouldn't cause much as much routing traffic as you think. Your details on the PSN routing algorithm were a bit wrong. First, there are three things that can cause a routing update to be generated: a link going up or down, the delay to a neighbor PSN changing more than a certain threshold, or the expiration of 50 seconds from the last time the PSN generated an update. Second, a PSN can generate an update at most every 10 seconds, no matter how much is changing in the network. Third, when a link goes down, it takes 60 seconds to bring it back up (this ensures that if a PSN was isolated from the network, it cannot bring up its links until it has received at least one routing update from every other PSN in the network; otherwise, its routing database would be incomplete). The estimated time for a routing update to propagate through the network is simply the network "diameter" (the minimum-hop path between the two most logically distant PSNs in the network) times the average propagation delay across the links. Flooding routing updates gets the highest priority in the PSN, so intra-PSN delays are usually negligible. Since routing updates cannot be generated at a greater rate than every 10 seconds by each PSN and at least every 50 seconds, it is easy to calculate the minimum, average, and maximum number of routing updates per minute on a network. And since the line up/down protocol keeps links down for at least 60 seconds, manually making links go up or down will probably not produce any more updates than you would have had anyway. Andy
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: Sat, 4-Apr-87 16:39:43 EST From: kzm@ACC-SB-UNIX.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Wiretapping ICMP messages
There have been a number of suggestions on this list recently that congestion-control could be enhanced if various IP implementations took note of ICMP Destination Unreachable messages, eg. if gateways cached the information and refused to send packets based on this cached information. It appears to me that this could cause problems when the routing and congestion algorithms are upgraded to include TOS-routing, Precedence, and Security. TOS-routing may not be available yet, but it appears to be considered a desirable addition in the (not too distant) future. When it is available, a destination might be reachable with one TOS value, but not with another. Similarly, there is work underway to have packets queued in switches (eg. in IMPs) according to their Precedence. So, a similar scenario (reachable with a high Precedence value, but not with a low value) could be applicable here also. The use of Security information as a routing criteria may be further into the future, but the same considerations apply. Of course, the cached information could be expanded to include TOS, Precedence and Security along with the destination address. The size of the cache would increase, but probably manageably-so for the time being while the majority of packets have the same TOS/Precedence /Security values. However, this could cause a "scaling-up" problem in the future. Also, the mechanism loses some of its usefulness when it can only be applied to packets of the same TOS, Precedence, and Security. Again, this might not a problem today when the majority of packets have the same TOS/Precedence/Security values, but does it cater to the future ? Keith McCloghrie ACC, Columbia Md.
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: Sat, 4-Apr-87 21:18:43 EST From: gnu@hoptoad.UUCP.UUCP To: mod.protocols.tcp-ip Subject: Re: multicast on ether
brescia@CCV.BBN.COM (Mike Brescia) writes: > The goal is to completely eliminate use of the broadcast address. TCP/IP > implementations may be overusing this feature, between ARP, RWHO, etc. I heartily agree with this goal. While working at Sun I noticed a large number of broadcast packets passing around, and this caused a few amusing problems, especially when these packets were addressed to user-mode daemons which swapped in over the ether. Note, however, that the current volume of broadcasts has the worst impact on hosts with old or badly designed Ethernet interfaces, e.g. 3Com boards with one or two receive buffers. These interfaces typically don't filter multicast packets anyway -- you can set a bit saying "receive multicast" or "toss multicast" and no more. Moving broadcast applications to multicast will only benefit hosts with more modern, e.g. AMD or Intel VLSI, interfaces. > Go to the ethernet number czar and get two (2) groups of 65536 (2^^16) > multicast addresses. By that, I mean the high order 32 bits are assigned by > the czar, and the low 16 bits are ours to play with. It might be worth looking at the filtering algorithms in the common Ethernet chips before figuring out the configuration of the multicast numbers. Typically they hash the addresses down to ~6 bits and the user supplies a 64-bit filter mask. We should try to match the number assignment to the hash functions. > Thus ARP, > instead of polluting all the hosts in the net, would send to the address > <ether-link>.8.6 (0x0806 is the number assigned to the address resolution > protocol). Virtually every host has to implement ARP so they will all be listening on <ether-link>.8.6 and there would be no benefit over just broadcasting. In the case of ARP, it would be better if the multicast address included the low byte of the Internet address you're looking for, so that hosts which don't know anything about that Internet address could ignore the packet in hardware. Note that most machines on one Ethernet will have the same high 3 bytes of their Internet address, so supplying the whole thing would be overkill. If a scheme like this gets worked out, I suggest that we allocate a bit in the ARP packets for "I listen to multicast for IP broadcasts", to tell a sending kernel which scheme to use (like the trailer protocol stuff). This begs the question of how the sending kernel decides how to send the ARP Request packet, but we're designing on the fly here anyway. Of course, a receiving kernel that handles multicasts should also accept the old broadcast packets for compatability.
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: Sun, 5-Apr-87 10:09:07 EST From: hwb@MCR.UMICH.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: multicast groups on ether
You have to watch out, though. Most interfaces I know of only support a limited set of multicast addresses (DEQNAs, I think, just have a table for fourteen or so addresses in general). You don't really want to end up having to listen to each and every packet in a multiprotocol gateway, just because your multicast address table in the EThernet device overflows. -- Hans-Werner
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: Sun, 5-Apr-87 11:21:15 EST From: Rudy.Nedved@H.CS.CMU.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Tcp/Ip vs a store & forward network
The concept of distributing internal configuration information to everyone in the world is too prone to failures from too much information. Assuming that people will extensively use the domain system to publish current routing information for mailboxes and dealing with cacheing and all the other problems is expecting too much. The idea is a nice one alas a very flawed one (from too much data). The trick at this pont is to just get a reasonable mail relaying mechansim up and to get rid of the host table. The MX records solve in a not so great way the problem of mail relaying for hosts not on the connected network alas a better algorithm has not been thought up that did not get shot down (heck, we can not even get packet routing right...how do you expect to get mail routing right?) Also many places are still using the host table mechanism and are starting to suffer because of the size problems....alas they have received temporary relief in the form of a 10% smaller NIC table. Let us keep an eye toward the future but make that first couple of steps instead of just dreaming about the future.... -Rudy
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: Sun, 5-Apr-87 11:57:12 EST From: Rudy.Nedved@H.CS.CMU.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: My Broadcast
Whoa! Encouraging people to find holes and then use them to make the local system programmers work on them is wrong. It is like encouraging people to find out if their neighbors lock their door during the day so they will. Do you really want that or do you want the theives to be caught? I want the theives to be caught and the ability to leave my door open. I don't want to fear my neighborhood or my users. I could spend many man years working on Unix security alone. The same is TRUE with TOPS-20. The worst is when you fix a security problem and some yo-yo finds out about it and then attacks some other remote site. The remote site gets pissed and says it can not afford to fix it....would you please deal with the yo-yo. -RUdy
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 1987 15:09-PST From: Steve Deering <deering@pescadero.stanford.edu> To: Hans-Werner Braun <hwb@MCR.UMICH.EDU>, hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore) Cc: tcp-ip@sri-nic.ARPA, tsuchiya@mitre-gateway.ARPA, x3s33-interest@mitre-gateway.ARPA Subject: Re: multicast on ether
From Hans-Werner Braun <hwb@MCR.UMICH.EDU>:
You have to watch out, though. Most interfaces I know of only support a
limited set of multicast addresses (DEQNAs, I think, just have a table
for fourteen or so addresses in general). You don't really want to end
up having to listen to each and every packet in a multiprotocol gateway,
just because your multicast address table in the EThernet device
overflows.
You don't have to listen to every packet, just every *multicast* packet,
when your multicast filter is exceeded. The DEQNA and other interfaces
provide such a reception mode. If we are just replacing broadcast packets
with multicast packets, listening to all multicasts is no worse than the
current situation of having to listen to all broadcasts. However, using
multicast addresses is much better for those hosts that *are* able to filter
multicasts adequately. Besides, it is not unreasonable to expect a
sophisticated multiprotocol gateway to have a sophisticated Ethernet
interface. The important thing is to stop sending unwanted packets to
non-gateway hosts.
I agree that we should conserve multicast addresses by looking out for
situations in which more than one application may reasonably use the same
multicast address, but I don't think we should be bound by the limitations
of current hardware. Once there is a demand for good multicast filtering,
the manufacturers will improve their products.
From: hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore)
It might be worth looking at the filtering algorithms in the common
Ethernet chips before figuring out the configuration of the multicast
numbers. Typically they hash the addresses down to ~6 bits and the
user supplies a 64-bit filter mask. We should try to match the number
assignment to the hash functions.
That's a good idea if they all use the same hash function. Both the AMD
7990 and the Intel 82586 send incoming multicast addresses though their
CRC generators and take 6 bits of the result as a hash value, as you
described. From the documents I have, it is not obvious that they
both use the same 6 bits of the CRC in the same order. (Can anyone say
for sure?) Are there other hashing functions in use in other interfaces?
Virtually every host has to implement ARP so they will all be listening
on <ether-link>.8.6 and there would be no benefit over just
broadcasting.
Hosts that aren't running IP aren't interested in ARP-for-IP packets.
Some of us share Ethernets with hosts running Pup, Chaos, XNS, or ISO
protocols. We don't like their broadcasts and they don't like ours.
If a scheme like this gets worked out, I suggest that we allocate a bit
in the ARP packets for "I listen to multicast for IP broadcasts", to
tell a sending kernel which scheme to use (like the trailer protocol
stuff).
I don't think any new bits are needed. Just send your ARP requests to
the multicast address, and if you don't get an answer, try the broadcast
address.
Steve Deering
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: Sun, 5-Apr-87 12:36:31 EST From: Mills@UDEL.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: ICMP As A Diagnostic Tool?
Miles, I suggest you invite co-BBNer Mike Brescia (X3662) for a beer and learn all about ICMP uses and abuses. This is not a frivolous suggestion. Dave
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: Sun, 5-Apr-87 12:48:13 EST From: Mills@UDEL.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: ICMP As A Diagnostic Tool?
Vint, Well, I don't know about that, although I (modestly) claim to have invented the term "ping" (Packet InterNet Groper) circa 1979. Mike Brescia at BBN, Hans-Werver Braun at U Michigan and others have a lot of grease under their fingernails. Having said that, I can't imagine an internet (small i), ISO or any other, viable in even the weakest sense without something like ICMP built into the protocol stack at outset. I even have to resist saying that agian for emphasis. Dave
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: Sun, 5-Apr-87 14:51:54 EST From: Mills@UDEL.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Wiretapping ICMP messages
Keith, The mechanism I suggested some time ago involves cacheing ICMP messages of selected types for a period longer than the typical TCP retransmission interval, but shorter than the typical "retry" interval, maybe a couple of minutes or so. I did not specify which message types should be cached and what detail information (TOS, etc.) should be saved, but did assume as much information as useful in the routing algorithm. My suggestion would not affect routing until a number of these messages (tbd) had been received within a period equal to some number of TCP retransmissions, maybe fifteen to thirty seconds. When that happened the local routing data base would be marked "down" for that destination net/TOS/whatever and the normal routing exchanges would do the rest. You will note this is functionally identical to the hard-to-reach concept used in the telephone network, except that routing updates per se are not used in that network (#4 ESS non-hierarchical routing honkers will be politely ignored here). I am not suggesting now as the optimum time to construct a definitive proposal on how to implement this concept in a j-random gateway, but am suggesting the concept ripe for experimentation in a real gateway, maybe even a fuzzball. Dave
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: Sun, 5-Apr-87 15:16:59 EST From: Mills@UDEL.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Time RFC 868
You can't keep "exact time" with RFC-868 time servers, since that protocol provides resolution only to the second. You should really and truly avoid TCP-based time, since not only is the accuracy udually degraded by the clank-and-bump of the connection-open sequence, but the sometimes meager resources of the time server can be strained. The protocol of choice is the Network Time Protocol (NTP), documented in RFC-958, for which Unix- based server and client programs are available (e.g. Mike Petry petry@trantor.umd.edu, Milo Medin medin@orion.arpa, both for 4.3 systems). As for the most accurate clocks in town, a fair number of "fuzzball" gateways and hosts are equipped with WWVB and WWV radio clocks that can deliver time accurate to a millisecond or two. Typical accuracies using NTP via ARPANET/MILNET are within 20 to 100 milliseconds, depending on the path and state of congestion. The fuzzballs are interconnected with NTP and, in some cases an interior-gateway protocol called hellospeak (c.f. RFC-891), so a failure in one radio clock does not frustrate the clockwatchers. At present the NSFNET Backbone sites are all synchronized to a WWVB radio clock at Boulder, CO, and capable of very accurate and robust time service using RFC-868 or NTP protocols. Use of TCP is adamantly discourged with the former and not available with the latter. UDP is the prefered envelope in any case. In addition, several WWVB-equipped servers are scattered about, including macom1.arpa (192.5.8.1), umd1.umd.edu (128.8.10.6) and ford1.arpa (182.5.0.1 - actually a GOES clock). Finally, a few hosts scattered over the swamps support less-accurate WWV radio which are also used as backups for the NTP system, including gw.umich.edu (35.1.1.1) and udel2.udel.edu (192.5.39.87). If present plans work out, the best places to watch clocks will be the NSFNET Backbone fuzzballs or other hosts synchronized directly to them. An announcement will be posted to this list when the details stabilize. Meanwhile, feel free watch one or more of the clocks above, with the first two (macom1.arpa or umd1.umd.edu) as the primary choice, but please don't use TCP. Dave
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: Sun, 5-Apr-87 15:29:39 EST From: ROODE@BIONET-20.ARPA.UUCP To: mod.protocols.tcp-ip Subject: anti-bridge comment
I don't think anyone has pointed out the following advantage of an IP gateway over a level 2 bridge between physical Ethernets. Ethernet broadcasts are filtered by IP gateways whereas in the case of bridges, full IP functionality between gateways requires that all Ethernets so joined see the combined broadcasts of each network in the group. -------
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: Sun, 5-Apr-87 18:09:00 EST From: deering@PESCADERO.STANFORD.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: multicast on ether
From Hans-Werner Braun <hwb@MCR.UMICH.EDU>:
You have to watch out, though. Most interfaces I know of only support a
limited set of multicast addresses (DEQNAs, I think, just have a table
for fourteen or so addresses in general). You don't really want to end
up having to listen to each and every packet in a multiprotocol gateway,
just because your multicast address table in the EThernet device
overflows.
You don't have to listen to every packet, just every *multicast* packet,
when your multicast filter is exceeded. The DEQNA and other interfaces
provide such a reception mode. If we are just replacing broadcast packets
with multicast packets, listening to all multicasts is no worse than the
current situation of having to listen to all broadcasts. However, using
multicast addresses is much better for those hosts that *are* able to filter
multicasts adequately. Besides, it is not unreasonable to expect a
sophisticated multiprotocol gateway to have a sophisticated Ethernet
interface. The important thing is to stop sending unwanted packets to
non-gateway hosts.
I agree that we should conserve multicast addresses by looking out for
situations in which more than one application may reasonably use the same
multicast address, but I don't think we should be bound by the limitations
of current hardware. Once there is a demand for good multicast filtering,
the manufacturers will improve their products.
From: hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore)
It might be worth looking at the filtering algorithms in the common
Ethernet chips before figuring out the configuration of the multicast
numbers. Typically they hash the addresses down to ~6 bits and the
user supplies a 64-bit filter mask. We should try to match the number
assignment to the hash functions.
That's a good idea if they all use the same hash function. Both the AMD
7990 and the Intel 82586 send incoming multicast addresses though their
CRC generators and take 6 bits of the result as a hash value, as you
described. From the documents I have, it is not obvious that they
both use the same 6 bits of the CRC in the same order. (Can anyone say
for sure?) Are there other hashing functions in use in other interfaces?
Virtually every host has to implement ARP so they will all be listening
on <ether-link>.8.6 and there would be no benefit over just
broadcasting.
Hosts that aren't running IP aren't interested in ARP-for-IP packets.
Some of us share Ethernets with hosts running Pup, Chaos, XNS, or ISO
protocols. We don't like their broadcasts and they don't like ours.
If a scheme like this gets worked out, I suggest that we allocate a bit
in the ARP packets for "I listen to multicast for IP broadcasts", to
tell a sending kernel which scheme to use (like the trailer protocol
stuff).
I don't think any new bits are needed. Just send your ARP requests to
the multicast address, and if you don't get an answer, try the broadcast
address.
Steve Deering
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: Sun, 5-Apr-87 23:38:00 EST From: anon@CITI.UMICH.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: overloaded station wagon
Shades of James Watt and the Beach Boys. Apologies, everyone.
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 1987 00:38 EDT From: anon@citi.umich.edu To: mckee@mitre.ARPA Cc: tcp-ip@sri-nic.ARPA Subject: Re: overloaded station wagon
Shades of James Watt and the Beach Boys. Apologies, everyone.
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: Mon, 6-Apr-87 02:15:26 EST From: usenet@ucbvax.UUCP To: mod.protocols.tcp-ip Subject: Re: My Broadcast
Dan -
I'm afraid you (and I, and any of the other old-timers who
care about security) are banging your head against a brick wall.
The philsophy behind Unix largely seems quite reminiscent of the
old ITS philsophy of "security through obscurity;" we must
entrust our systems and data to a open-ended set of youthful
hackers (the current term is "gurus") who have mastered the
arcane knowledge.
The problem is further exacerbated by the multitude of slimy
vendors who sell Unix boxes without sources and without an
efficient means of dealing with security problems as they
develop.
I don't see any relief, however. There are a lot of
politics involved here. Some individuals would rather muzzle
knowledge of Unix security problems and their fixes than see them
fixed. I feel it is *criminal* to have this attitude on the DDN,
since our national security in wartime might ultimately depend
upon it. If there is such a breach, those individuals will be
better off if the Russians win the war, because if not there will
be a Court of Inquiry to answer...
It may be necessary to take matters into our own hands, as
you did once before. I am seriously considering offering a cash
reward for the first discoverer of a Unix security bug, provided
that the bug is thoroughly documented (with both cause and fix).
There would be a sliding cash scale based on how devastating the
bug is and how many vendors' systems it affects. My intention
would be to propagate the knowledge as widely as possible with
the express intension of getting these bugs FIXED everywhere.
Knowledge is