----MESSAGE-BEGIN---- [860602-175604-178%40Xerox] <1986060211034200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Murray.pa@XEROX.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Adaptive SMTP Timeouts Message-ID: <860602-175604-178@Xerox> Date: Mon, 2-Jun-86 15:03:42 EDT Article-I.D.: Xerox.860602-175604-178 Posted: Mon Jun 2 15:03:42 1986 Date-Received: Tue, 3-Jun-86 02:32:19 EDT References: <8605302157.AA21314@sering.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa An idea that we have found very helpful... Our mailer keeps outgoing mail sorted by host. Hosts are split into two categories: healthy and sick. While there is work to do on the healthy queue, the mailer ignores the sick hosts. Whenever the mailer empties the healthy queue, it tries the host on the front of the sick queue. (If that fails, it gets moved to the end of the sick queue.) The idea is to avoid having the mailer bang its head against hosts that are known to be causing trouble. Occasionally mail to a host that isn't really very sick takes much longer that we would like. This happens when the sick queue is very long and the mailer is busy so the sick queue doesn't turn over very fast. So far, this hasn't bothered us enough to do anything about it. Along the same lines, we also keep mail to a host sorted, but not quite chronologically. Whenever the mailer tries to send a message and fails, that message gets moved to the end of the queue. Occasionally, this lets the rest of the mail get through when one particular message is having/causing troubles. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606021934.AA16385%40ucbvax.Berkeley.EDU] <1986060211355400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mills@DCN6.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: On Etherbunnies and swamp creatures Message-ID: <8606021934.AA16385@ucbvax.Berkeley.EDU> Date: Mon, 2-Jun-86 15:35:54 EDT Article-I.D.: ucbvax.8606021934.AA16385 Posted: Mon Jun 2 15:35:54 1986 Date-Received: Mon, 2-Jun-86 23:37:09 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 122 Approved: tcp-ip@sri-nic.arpa Folks, You may know the Vitalink TransLAN satellite network architecture consists of a broadcast-type satellite channel connecting a (perhaps large) number of local Ethernets and forming one grand and glorious global Ethernet. Clever filtering attempts to keep local traffic off`the broadcast channel, but Ethernet broadcast-type packets are heard everywhere. The natural, but naive, urge is to simply splice the channel directly to the local Ethernet, which may or may not have a path to the Internet, and watch the Etherbunnies pop out. Hans-Werner Braun at U Michigan has been trying to connect the USAN network, which uses TransLAN architecture, to the world with a fuzzball gateway. As could be predicted with any Internet community where local nets and subnets can join and leave the system willy-nilly without telling anybody about hosts, gateways or anything, the poor fuzzball quickly drowned in the swamp. Following is a summary of some of the issues, together with a proposal how some of them can be resolved. The biggest swamprat turns out to be pesky broadcasts (rwho, etc.) so beloved by Unix hosts. One of these splashes on the local cable, probably tossed by a j-random host on a j-random net half-way across the country with a net number nobody ever heard before. We all know this is not an uncommon occurance even without TransLAN. Now, fuzzballs and probably other swamp creatures can deal with multiple subnets on the same cable and even multiple nets on the same cable, but can't pull Etherbunnies from a hat unless told what to do with them. Since Hans-Werner's fuzzy was 800 miles and two networks downstream from the nearest EGP-speaking gateway, he simply tossed the packets upstream to that gateway, which promptly blat an ICMP unreachable back (oops) down a black hole, since it never heard of the drat net. Well, there were quite a number of these things, so the EGP gateway (also a fuzzy) hollered mayhem to its log file. This experience and previous experience with Martians (bogus packets to and/or from address 127.0.0.0) suggests that it's a mighty bad thing to allow strictly local creatures, broadcasts or otherwise, to escape their native swamps. I propose that a filtering mechanism be included in the gateway requirements specified in RFC-985. The mechanisms amounts to deleting packets with IP destination addresses falling into certain ranges. A gateway receiving such a packet would not forward it or return any packet whatsoever in response. This means no ICMP messages, no ARPs replies or nothin'. If the gateway is also acting as a local host, it may in fact take action, but only in a context strictly local to the same network. Following is a list of these addresses. Some of these are called out in RFC-960 and designated "reserved." Others are called out in RFC-922 and elsewhere and designated "local broadcast." The remaining are called out in RFC-960 and designated "local use." These are intended for use by diskless things that may come on-cable with incomplete configuration information and need to determine their particular environment by interaction with a local agent. The interpretation and use of the address and mask are described in RFC-950, among other places. (* = "don't care") 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class/Description Address Mask ----------------- ------- ---- A reserved 000.000.000.000 255.000.000.000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0|* * * * * * * *|* * * * * * * *|* * * * * * * *| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A reserved 127.000.000.000 255.000.000.000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 1 1 1 1 1 1|* * * * * * * *|* * * * * * * *|* * * * * * * *| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A local use 000.000.000.000 128.255.255.255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-k-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 * * * * * * *|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A local broadcast 000.255.255.255 128.255.255.255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 * * * * * * *|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B reserved 128.000.000.000 255.255.000.000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|* * * * * * * *|* * * * * * * *| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B reserved 191.255.000.000 255.255.000.000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 1 1 1 1 1 1|1 1 1 1 1 1 1 1|* * * * * * * *|* * * * * * * *| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B local use 128.000.000.000 192.000.255.255 +-+-+m+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 * * * * * *|* * * * * * * *|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B local broadcast 128.000.255.255 192.000.255.255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 * * * * * *|* * * * * * * *|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C reserved 192.000.000.000 255.255.255.000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|* * * * * * * *| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C reserved 223.255.255.000 255.255.255.000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|* * * * * * * *| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C local use 192.00p.000.000 224.000.000.255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 * * * * *|* * * * * * * *|* * * * * * * *|0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C local broadcast 192.000.000.255 224.000.000.255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 * * * * *|* * * * * * * *|* * * * * * * *|1 1 1 1 1 1 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D reserved 224.000.000.000 224.000.000.000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 * * * * *|* * * * * * * *|* * * * * * * *|* * * * * * * *| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that the above has no provision for subnets as described in RFC-950. Assuming the gateway configuration includes the subnet address(es) and mask(s), one simply adds entries to the above list in the obvious way. There has been some discussion on how to deal with proliferated broadcasts by using information implicit in the local-net (subnetwork) address. I believe on the basis of clarity, simplicity and separation of function that this is not the right answer. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986060218451500> Received: from DCN8.ARPA by SRI-NIC.ARPA with TCP; Mon 2 Jun 86 11:46:05-PDT Date: 02-Jun-86 18:45:15-UT From: mills@dcn6.arpa Subject: On Etherbunnies and swamp creatures To: tcp-ip@sri-nic.arpa Folks, You may know the Vitalink TransLAN satellite network architecture consists of a broadcast-type satellite channel connecting a (perhaps large) number of local Ethernets and forming one grand and glorious global Ethernet. Clever filtering attempts to keep local traffic off`the broadcast channel, but Ethernet broadcast-type packets are heard everywhere. The natural, but naive, urge is to simply splice the channel directly to the local Ethernet, which may or may not have a path to the Internet, and watch the Etherbunnies pop out. Hans-Werner Braun at U Michigan has been trying to connect the USAN network, which uses TransLAN architecture, to the world with a fuzzball gateway. As could be predicted with any Internet community where local nets and subnets can join and leave the system willy-nilly without telling anybody about hosts, gateways or anything, the poor fuzzball quickly drowned in the swamp. Following is a summary of some of the issues, together with a proposal how some of them can be resolved. The biggest swamprat turns out to be pesky broadcasts (rwho, etc.) so beloved by Unix hosts. One of these splashes on the local cable, probably tossed by a j-random host on a j-random net half-way across the country with a net number nobody ever heard before. We all know this is not an uncommon occurance even without TransLAN. Now, fuzzballs and probably other swamp creatures can deal with multiple subnets on the same cable and even multiple nets on the same cable, but can't pull Etherbunnies from a hat unless told what to do with them. Since Hans-Werner's fuzzy was 800 miles and two networks downstream from the nearest EGP-speaking gateway, he simply tossed the packets upstream to that gateway, which promptly blat an ICMP unreachable back (oops) down a black hole, since it never heard of the drat net. Well, there were quite a number of these things, so the EGP gateway (also a fuzzy) hollered mayhem to its log file. This experience and previous experience with Martians (bogus packets to and/or from address 127.0.0.0) suggests that it's a mighty bad thing to allow strictly local creatures, broadcasts or otherwise, to escape their native swamps. I propose that a filtering mechanism be included in the gateway requirements specified in RFC-985. The mechanisms amounts to deleting packets with IP destination addresses falling into certain ranges. A gateway receiving such a packet would not forward it or return any packet whatsoever in response. This means no ICMP messages, no ARPs replies or nothin'. If the gateway is also acting as a local host, it may in fact take action, but only in a context strictly local to the same network. Following is a list of these addresses. Some of these are called out in RFC-960 and designated "reserved." Others are called out in RFC-922 and elsewhere and designated "local broadcast." The remaining are called out in RFC-960 and designated "local use." These are intended for use by diskless things that may come on-cable with incomplete configuration information and need to determine their particular environment by interaction with a local agent. The interpretation and use of the address and mask are described in RFC-950, among other places. (* = "don't care") 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class/Description Address Mask ----------------- ------- ---- A reserved 000.000.000.000 255.000.000.000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0|* * * * * * * *|* * * * * * * *|* * * * * * * *| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A reserved 127.000.000.000 255.000.000.000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 1 1 1 1 1 1|* * * * * * * *|* * * * * * * *|* * * * * * * *| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A local use 000.000.000.000 128.255.255.255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-k-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 * * * * * * *|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A local broadcast 000.255.255.255 128.255.255.255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 * * * * * * *|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B reserved 128.000.000.000 255.255.000.000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|* * * * * * * *|* * * * * * * *| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B reserved 191.255.000.000 255.255.000.000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 1 1 1 1 1 1|1 1 1 1 1 1 1 1|* * * * * * * *|* * * * * * * *| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B local use 128.000.000.000 192.000.255.255 +-+-+m+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 * * * * * *|* * * * * * * *|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B local broadcast 128.000.255.255 192.000.255.255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 * * * * * *|* * * * * * * *|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C reserved 192.000.000.000 255.255.255.000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|* * * * * * * *| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C reserved 223.255.255.000 255.255.255.000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|* * * * * * * *| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C local use 192.00p.000.000 224.000.000.255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 * * * * *|* * * * * * * *|* * * * * * * *|0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C local broadcast 192.000.000.255 224.000.000.255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 * * * * *|* * * * * * * *|* * * * * * * *|1 1 1 1 1 1 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D reserved 224.000.000.000 224.000.000.000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 * * * * *|* * * * * * * *|* * * * * * * *|* * * * * * * *| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that the above has no provision for subnets as described in RFC-950. Assuming the gateway configuration includes the subnet address(es) and mask(s), one simply adds entries to the above list in the obvious way. There has been some discussion on how to deal with proliferated broadcasts by using information implicit in the local-net (subnetwork) address. I believe on the basis of clarity, simplicity and separation of function that this is not the right answer. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12211785351.33.HEDRICK%40RED.RUTGERS.EDU] <1986060222202600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HEDRICK@RED.RUTGERS.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: more interesting features of 4.2 Message-ID: <12211785351.33.HEDRICK@RED.RUTGERS.EDU> Date: Tue, 3-Jun-86 02:20:26 EDT Article-I.D.: RED.12211785351.33.HEDRICK Posted: Tue Jun 3 02:20:26 1986 Date-Received: Tue, 3-Jun-86 21:52:14 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 31 Approved: tcp-ip@sri-nic.arpa I have finally found a mechanism that seems to work for getting Suns to route automatically. It turns out that you can specify routing entries that will cause a host to treat destinations on that network as local. I.e. it will issue ARP's for them, just as if they were on the local Ethernet. The correct form is route add 0 if you want to set this up as a default. It turns out that all of our diskless Sun 3's come up with such a default address automatically. We believe that this is due to a bug, but it is a fairly happy one, from my point of view. I have modified our gateway software to be able to handle a network where the hosts issue ARP's for everyone. The gateway responds to ARPs for hosts on the other side of the gateway. It also responds to ARPs for hosts on the other side of gateways that don't know about the convention (giving their Ethernet address, of course, not its own -- this is an ARP-level equivalent of an ICMP redirect). This strategy has a number of advantages from my point of view: - it requires no action on the part of the user, at least until Sun fixes their bug, if it is one. - the entry need not have wired-in knowledge of the gateway's address. If we change gateway configurations, this will continue to work. - if we have more than one gateway, and they talk to each other, we can take advantage of their redundancy, since we don't have specific routings built into the table. I'm sure the gateway committee will come up with a more elegant way to do things, but this looks like the best alternative to the problem I have been posing for some time. It involves no modification to Unix, does not depend upon hosts failing to validate ICMP redirects, etc. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860603104027.9.DCP%40FIREBIRD.SCRC.Symbolics.COM] <1986060306400000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@SCRC-QUABBIN.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Adaptive SMTP Timeouts Message-ID: <860603104027.9.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Tue, 3-Jun-86 10:40:00 EDT Article-I.D.: FIREBIRD.860603104027.9.DCP Posted: Tue Jun 3 10:40:00 1986 Date-Received: Wed, 4-Jun-86 17:05:00 EDT References: <860602-175604-178@Xerox> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 41 Approved: tcp-ip@sri-nic.arpa Date: Mon, 2 Jun 86 12:03:42 PDT From: Murray.pa@Xerox.COM An idea that we have found very helpful... Our mailer keeps outgoing mail sorted by host. Hosts are split into two categories: healthy and sick. While there is work to do on the healthy queue, the mailer ignores the sick hosts. Whenever the mailer empties the healthy queue, it tries the host on the front of the sick queue. (If that fails, it gets moved to the end of the sick queue.) The idea is to avoid having the mailer bang its head against hosts that are known to be causing trouble. We do something like this. We keep track of up and down hosts, and when processing mail skip the hosts that are believed down. Therefore, we don't concentrate on one particular host (which might drive that host crazy). I think we do it this way because one message is often destined for many hosts. Occasionally mail to a host that isn't really very sick takes much longer that we would like. This happens when the sick queue is very long and the mailer is busy so the sick queue doesn't turn over very fast. So far, this hasn't bothered us enough to do anything about it. Obvious solution: Periodically declare sick hosts up, or slightly more conservatively, declare the host suitable for a probe. If it really is sick, you'll know soon enough. You only have to do this for one message. If it isn't sick, you can requeue the tardy messages. Along the same lines, we also keep mail to a host sorted, but not quite chronologically. Whenever the mailer tries to send a message and fails, that message gets moved to the end of the queue. Occasionally, this lets the rest of the mail get through when one particular message is having/causing troubles. When a message is causing troubles, how long does it take a human to realize it and take corrective action. If it stayed at the head of the queue, I can imagine a human would notice sooner by either having no mail get through at all, or the queue for the troublesome host keeps growing instead of stays at some "respectable" number. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606031912.AA08576%40ucbvax.Berkeley.EDU] <1986060310245300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MILLS@USC-ISID.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: more interesting features of 4.2 Message-ID: <8606031912.AA08576@ucbvax.Berkeley.EDU> Date: Tue, 3-Jun-86 14:24:53 EDT Article-I.D.: ucbvax.8606031912.AA08576 Posted: Tue Jun 3 14:24:53 1986 Date-Received: Wed, 4-Jun-86 17:06:50 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa In response to the message sent 3 Jun 86 02:20:26 EDT from HEDRICK@RED.RUTGERS.EDU Charles, I think what you have accomplished is what has been viariously called the "ARP hack" or "promiscuous redirects." The technique has been proposed as a convenient way of transition to the subnet scheme proposed in RFC-950 and specified as a requirement in RFC-985. The technique has its own peculiar hazards and is viewed by some as outright dangerous. Nevertheless, it has proven useful in cases like yours (and ours). What this all means is that the Sun implementation could be considered a feature, not a bug. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986060310245301> Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Tue 3 Jun 86 11:25:16-PDT Date: 3 Jun 1986 14:24:53 EDT From: MILLS@USC-ISID.ARPA Subject: Re: more interesting features of 4.2 To: HEDRICK@RED.RUTGERS.EDU, tcp-ip@SRI-NIC.ARPA cc: MILLS@USC-ISID.ARPA In response to the message sent 3 Jun 86 02:20:26 EDT from HEDRICK@RED.RUTGERS.EDU Charles, I think what you have accomplished is what has been viariously called the "ARP hack" or "promiscuous redirects." The technique has been proposed as a convenient way of transition to the subnet scheme proposed in RFC-950 and specified as a requirement in RFC-985. The technique has its own peculiar hazards and is viewed by some as outright dangerous. Nevertheless, it has proven useful in cases like yours (and ours). What this all means is that the Sun implementation could be considered a feature, not a bug. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606032022.AA05749%40sally.UTEXAS.EDU] <1986060312223300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: jsq@SALLY.UTEXAS.EDU (John Quarterman) Newsgroups: mod.protocols.tcp-ip Subject: Re: more interesting features of 4.2 Message-ID: <8606032022.AA05749@sally.UTEXAS.EDU> Date: Tue, 3-Jun-86 16:22:33 EDT Article-I.D.: sally.8606032022.AA05749 Posted: Tue Jun 3 16:22:33 1986 Date-Received: Wed, 4-Jun-86 17:09:56 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 1 Approved: tcp-ip@sri-nic.arpa Perhaps there should be an RFC on the ARP hack. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12212027261.22.JNC%40XX.LCS.MIT.EDU] <1986060320291700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa") Newsgroups: mod.protocols.tcp-ip Subject: Re: more interesting features of 4.2 Message-ID: <12212027261.22.JNC@XX.LCS.MIT.EDU> Date: Wed, 4-Jun-86 00:29:17 EDT Article-I.D.: XX.12212027261.22.JNC Posted: Wed Jun 4 00:29:17 1986 Date-Received: Wed, 4-Jun-86 20:16:08 EDT References: <8606032022.AA05749@sally.UTEXAS.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa RFC917 by Jeff Mogul talks about it in some length. Note that this approach is not advised as a general way to do routing in the host IP layer since the ARP layer was never designed to be a path for routing information interchange, and thus has lots of deficiencies when so used. A socket wrench makes a poor hammer. Jeff lists some in his memo; there are others, such as not being able to handle TOS routing, etc. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12212068498.49.HEDRICK%40RED.RUTGERS.EDU] <1986060400154800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: Re: more interesting features of 4.2 Message-ID: <12212068498.49.HEDRICK@RED.RUTGERS.EDU> Date: Wed, 4-Jun-86 04:15:48 EDT Article-I.D.: RED.12212068498.49.HEDRICK Posted: Wed Jun 4 04:15:48 1986 Date-Received: Wed, 4-Jun-86 19:49:07 EDT References: <12212027261.22.JNC@XX.LCS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 42 Approved: tcp-ip@sri-nic.arpa I'd rather use a socket wrench as a hammer than my bare hands. I'm eagerly awaiting the gateway group's proposals, and their implementation by all of the vendors supplying systems that we use. Until then, ARP-based routing is something that I can do that will work, and that does not abuse any standards too badly. I don't intend it to be for routing information interchange in the general sense. The gateways will use other protocols among themselves. What I need is a way to get information from the gateways to the hosts. I just reread the relevant section of 917, and in fact Mogul says that ARP-based subnetting is a reasonable strategy. His only criticism, other than the fact that it can only be implemented if you have broadcasts (which of course we do), is that there may be trouble recovering if a gateway goes down. In fact it is no more difficult to recover from gateway failure using ARP-based routing than using any other scheme. When a connection is about to time out, the system should attempt to recompute the route. It is just as easy to purge the ARP entry and issue another ARP as to purge the routing entry and do whatever you would normally do to find another routing at that level. In fact 4.2 does neither. But it does time out ARP entries, so eventually it will correct routings when ARP are being used to discover routes. Most alternative methods don't do even this well. I am assuming that our gateways will talk to each other, and arrange it so that the right gateway responds. That is, if one gateway goes down, and there is another route, the backup gateway will begin responding to ARP requests. In fact that gateway technology we are using (Stanford's) has this ability. Note that I have gone one step beyond the ARP-based subnetting described in RFC 917, in that I also use ARP's to identify routes to hosts outside our class B network. We currently have 3 different gateways to the outside world. One handles a single class C network. One handles a class B network and a class C network. The third is our Arpanet gateway, to which we send all other traffic. As the supercomputer network and other NSF-sponsored networking develop, we are likely to start moving traffic for certain other Universities from the Arpanet to one of the other networks. We do not want to have to change routing tables in every host when we make such a change. What is TOS routing? ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986060404493000> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Wed 4 Jun 86 12:04:17-PDT Date: 4 Jun 1986 11:49:30 PDT From: POSTEL@USC-ISIB.ARPA Subject: re: ARP Hacks & Interesting things in .... To: tcp-ip@SRI-NIC.ARPA Hi. People interested in ARP hacks should check this obscure memo by some guy, it is RFC-925. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606041338.AA18083%40sally.UTEXAS.EDU] <1986060405383500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jsq@SALLY.UTEXAS.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: more interesting features of 4.2 Message-ID: <8606041338.AA18083@sally.UTEXAS.EDU> Date: Wed, 4-Jun-86 09:38:35 EDT Article-I.D.: sally.8606041338.AA18083 Posted: Wed Jun 4 09:38:35 1986 Date-Received: Wed, 4-Jun-86 23:54:39 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa Right. I had assumed RFC917 was completely superseded when RFC950 came out, but I see it still has quite a bit of useful information in it. The ARP hack has many deficiencies, as you point out, but many of us don't have much choice since we have systems to which we don't have the source and for which the vendor has not yet implemented subnets (e.g., TOPS-20, Silicon Graphics, Integrated Solutions, Bridge, Sun, VMS, Ridge, etc. ad nauseum). Perhaps the MIT ICMP host redirect method is the better interim solution. Does anyone have anything more to add on that than what's in RFC917? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986060405560000> Received: from su-navajo.arpa by SRI-NIC.ARPA with TCP; Wed 4 Jun 86 12:58:50-PDT Received: by su-navajo.arpa with Sendmail; Wed, 4 Jun 86 12:56:49 pdt Date: 4 Jun 1986 1256-PDT (Wednesday) From: Jeff Mogul To: Charles Hedrick Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: more interesting features of 4.2 ("ARP Hack") I just reread the relevant section of 917, and in fact Mogul says that ARP-based subnetting is a reasonable strategy. Actually, about the nicest thing I said about it is that it is "somewhat unsatisfactory." I certainly did not intend this to be an excuse for IP vendors who aren't willing/able to get their acts together. Granted, this is less annoying than those hosts which spray broadcasts all over everything, or those that try to act as gateways when they aren't supposed to, but it really isn't that hard to get this right. I also (now) regret the term "ARP-based subnetting", for its implication that ARP is in any way central to the use of subnets. I don't have a perfect term, but something like "ARP-compatible subnetting" or "subnet-extended ARP" would be less misleading. I sure wish people who design widely-used IP implementations would test their bright ideas on the Internet community before shipping half a million workstations. -Jeff P.S.: Noel, you warned me. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606041506.AA27808%40guenevere.Purdue.EDU] <1986060407063800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: narten@PURDUE.EDU ("Thomas Narten") Newsgroups: mod.protocols.tcp-ip Subject: Re: more interesting features of 4.2 Message-ID: <8606041506.AA27808@guenevere.Purdue.EDU> Date: Wed, 4-Jun-86 11:06:38 EDT Article-I.D.: guenever.8606041506.AA27808 Posted: Wed Jun 4 11:06:38 1986 Date-Received: Wed, 4-Jun-86 23:45:36 EDT References: <12212068498.49.HEDRICK@RED.RUTGERS.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa >But [UNIX] does time out ARP entries, so eventually it will correct >routings when ARP are being used to discover routes. This is not always true. ARP entries that are not referenced for X minutes (20 for us) are deleted. This is not the same thing as saying IP to Ethernet mappings that aren't valid get deleted. If you continue to try to send to a host, the ARP entry continues to get referenced and will not time out at all. Hence, it is not clear that having paths through multiple gateways to the same destination will always be used the way one expects if the currently used gateway crashes. Thomas ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606050225.AA19266%40ucbvax.Berkeley.EDU] <1986060410150100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: MILLS@USC-ISID.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: more interesting features of 4.2 Message-ID: <8606050225.AA19266@ucbvax.Berkeley.EDU> Date: Wed, 4-Jun-86 14:15:01 EDT Article-I.D.: ucbvax.8606050225.AA19266 Posted: Wed Jun 4 14:15:01 1986 Date-Received: Thu, 5-Jun-86 09:23:25 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 36 Approved: tcp-ip@sri-nic.arpa In response to the message sent 4 Jun 86 04:15:48 EDT from HEDRICK@RED.RUTGERS.EDU Charles, I'm not sure who you mean by the "gateway group." The old Gateway Algorithms and Data Structures (GADS) Task Force, which I chaired, has been dissolved and precipitated into the Internet Engineering (INENG) Task Force, Chaired by Mike Corrigan, and the Internet Architecture (INARC) Task FOrce, which I chair. THe INENG is concerned about relatively near-term (a couple of years) issues, while the INARC is looking further out. Both of these task forces are concerned about gateways, among many other issues. The NSF Network Technical Advisory Group (NTAG), which serves as advisor to NSF staff on network issues in general, including gateways for the explosively growing NSF Internet community, created an ad-hoc subcommittee to establish a first cut at Internet gateway requirements in general and the NSF community in particular. That subcommittee, also chaired by me, produced in close cooperation with the Internet Activities Board, chaired by Dave Clark, a working document that was published as RFC-985. You can see there is no single "gateway group," but a number of committees and task forces very much concerned with the issues being discussed here. The chairs mentioned above watch this list and others for developing issues and consider them carefully when constructing agendae and moderating meeting discussion. Nevertheless, the issues wandering around here on gateway routing, ARP, redirects and cranky Unix systems are incredibly complicated, easily misunderstood and highly flame-able. Speaking for myself and the above committees, we would very much like to harden the model proposed in RFC-985, especially in the technical details involved with multi-net cables, host-gateway routing, address resolution, redirects and so forth on Ethernets, TransLANs and similar technologies. If you have specific questions or comments you think unsuitable for this list, you are welcome to jiggle my chain or the others mentioned in RFC-985. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606050418.AA02742%40ucbvax.Berkeley.EDU] <1986060410493000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: POSTEL@USC-ISIB.ARPA Newsgroups: mod.protocols.tcp-ip Subject: re: ARP Hacks & Interesting things in .... Message-ID: <8606050418.AA02742@ucbvax.Berkeley.EDU> Date: Wed, 4-Jun-86 14:49:30 EDT Article-I.D.: ucbvax.8606050418.AA02742 Posted: Wed Jun 4 14:49:30 1986 Date-Received: Thu, 5-Jun-86 09:51:43 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa Hi. People interested in ARP hacks should check this obscure memo by some guy, it is RFC-925. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606050253.AA00383%40ucbvax.Berkeley.EDU] <1986060411560000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mogul@SU-NAVAJO.ARPA (Jeff Mogul) Newsgroups: mod.protocols.tcp-ip Subject: Re: more interesting features of 4.2 ("ARP Hack") Message-ID: <8606050253.AA00383@ucbvax.Berkeley.EDU> Date: Wed, 4-Jun-86 15:56:00 EDT Article-I.D.: ucbvax.8606050253.AA00383 Posted: Wed Jun 4 15:56:00 1986 Date-Received: Thu, 5-Jun-86 09:24:36 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa I just reread the relevant section of 917, and in fact Mogul says that ARP-based subnetting is a reasonable strategy. Actually, about the nicest thing I said about it is that it is "somewhat unsatisfactory." I certainly did not intend this to be an excuse for IP vendors who aren't willing/able to get their acts together. Granted, this is less annoying than those hosts which spray broadcasts all over everything, or those that try to act as gateways when they aren't supposed to, but it really isn't that hard to get this right. I also (now) regret the term "ARP-based subnetting", for its implication that ARP is in any way central to the use of subnets. I don't have a perfect term, but something like "ARP-compatible subnetting" or "subnet-extended ARP" would be less misleading. I sure wish people who design widely-used IP implementations would test their bright ideas on the Internet community before shipping half a million workstations. -Jeff P.S.: Noel, you warned me. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [SRA.12212217826.BABYL%40XX.LCS.MIT.EDU] <1986060413560000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: SRA@XX.LCS.MIT.EDU (Rob Austein) Newsgroups: mod.protocols.tcp-ip Subject: Contact names, WKS RRs, redesigning known universe Message-ID: Date: Wed, 4-Jun-86 17:56:00 EDT Article-I.D.: XX.SRA.12212217826.BABYL Posted: Wed Jun 4 17:56:00 1986 Date-Received: Thu, 5-Jun-86 09:26:41 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 63 Approved: tcp-ip@sri-nic.arpa (This is going to TCP-IP because the discussion started there. Any followup should be conducted on NAMEDROPPERS, I think.) I'd like to (belatedly) second Joe Weening's suggestion that we use the domain system to supply a contact name service. If we were designing the Internet from scratch, I'd say to use Chaosnet style contact names, which are a big win. But we're not designing from scratch. Using the domain system would solve two distinct problems that have arisen lately. One is the contact-names problem under discussion on TCP-IP, the other is the inadaquacy of the current IN WKS RR format (see NAMEDROPPERS archives for details). Here's my proposed RR formats . IN SERV . CH SERV is the service name (contact name analog). Domain name is the name of the host supporting it. and are as in A RRs (note that is a 16 bit port number. Chaosnet doesn't need this, since chaosnet has contact names, but it would be nice to be able to have a WKS analog for Chaosnet. The address fields are there for the same reason as in the WKS RR; some host might offer different services on different network interfaces. I'm not convinced this is reasonable, but it was considered necessary in the original WKS format. We might want to add a field to the IN class format, same logic (the analog for Chaosnet would be another text string) Examples: SMTP.XX.LCS.MIT.EDU IN SERV 10.0.0.44 25 TFTP.XX.LCS.MIT.EDU IN SERV 10.0.0.44 69 FILE.XX.LCS.MIT.EDU CH SERV MIT.EDU 2420 TIME.XX.LCS.MIT.EDU CH SERV MIT.EDU 2420 or (with protocols ids) SMTP.XX.LCS.MIT.EDU IN SERV 10.0.0.44 6 25 TFTP.XX.LCS.MIT.EDU IN SERV 10.0.0.44 17 69 FILE.XX.LCS.MIT.EDU CH SERV MIT.EDU 2420 CHANNEL TIME.XX.LCS.MIT.EDU CH SERV MIT.EDU 2420 SIMPLE We might also want to put RRs for all the standard services (ie, the ones known to the protocol czar) in at the root node. This would be useful for people who want to code with a contact name approach, and shouldn't be too much overhead. Queries like {IN SERV *.XX.LCS.MIT.EDU} should work fine and give a series of RRs listing all funny IP protocols supported by XX. I think this proposal solves serveral problems without creating any new ones. It is not the optimal solution to the contact name problem, but it will work and uses existing technology. Comments? --Rob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12212286176.22.JNC%40XX.LCS.MIT.EDU] <1986060420113300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa") Newsgroups: mod.protocols.tcp-ip Subject: Re: more interesting features of 4.2 Message-ID: <12212286176.22.JNC@XX.LCS.MIT.EDU> Date: Thu, 5-Jun-86 00:11:33 EDT Article-I.D.: XX.12212286176.22.JNC Posted: Thu Jun 5 00:11:33 1986 Date-Received: Thu, 5-Jun-86 09:54:30 EDT References: <8606041338.AA18083@sally.UTEXAS.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa The so-called 'MIT ICMP' thing is not a change to the spec, merely one of way doing things of the ways allowed by the spec. There really isn't a lot to say beyond what's in RFC917. The 'ARP hack' is necessary for some machines since the per-host ICMP thing doesn't work if the source host doesn't realize that the destination is on another wire. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606050414.AA09922%40ngp.UTEXAS.EDU] <1986060420140600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: dan@NGP.UTEXAS.EDU (Dan Reynolds) Newsgroups: mod.protocols.tcp-ip Subject: 4.2 TCP question Message-ID: <8606050414.AA09922@ngp.UTEXAS.EDU> Date: Thu, 5-Jun-86 00:14:06 EDT Article-I.D.: ngp.8606050414.AA09922 Posted: Thu Jun 5 00:14:06 1986 Date-Received: Thu, 5-Jun-86 10:00:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa A question on 4.2 BSD TCP: what is the proper response to a "keep-alive" packet for which the receiving TCP can find no TCB? According to the RFC, the correct response is to generate a segment bearing an RST and formulate the SEG.SEQ and SEG.ACK so as to make them acceptable. My TCP implementation did exactly that. However, the 4.2 TCP on the other end blithely continued to send segments to the non-existent TCB in complete defiance of the RST's. Does anyone know why (more precisely, has anyone seen this type of behavior before)? Dan Reynolds Computation Center The University of Texas at Austin Austin, TX 78712 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860605185352.917320%40MIT-MULTICS.ARPA] <1986060510530000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Vinograd@MIT-MULTICS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: tn3270 Message-ID: <860605185352.917320@MIT-MULTICS.ARPA> Date: Thu, 5-Jun-86 14:53:00 EDT Article-I.D.: MIT-MULT.860605185352.917320 Posted: Thu Jun 5 14:53:00 1986 Date-Received: Thu, 5-Jun-86 23:49:26 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa Greg: As you know, we sucessfully ported an early version of tn3270 to a Sun, and now support the terminal negociation both for our client and server telnet. We would like to update our copy with the latest version. How can I arrange to get the latest source ? We are also trying to move the current version to a Masscomp, and are having problems interfacing to the Masscomp window system, in full screen mode. Do you know of anyone who has done such a port, name/phone number or EM address would be most useful. Thanks in advance Dave Vinograd (Spartacus) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606052118.AA06342%40sri-spam.arpa] <1986060513181200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: robert@SRI-SPAM.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: tcp on SUN computers. Message-ID: <8606052118.AA06342@sri-spam.arpa> Date: Thu, 5-Jun-86 17:18:12 EDT Article-I.D.: sri-spam.8606052118.AA06342 Posted: Thu Jun 5 17:18:12 1986 Date-Received: Fri, 6-Jun-86 00:30:22 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 46 Approved: tcp-ip@sri-nic.arpa Hello there, I have a question regarding the implementation of TCP used on the SUN computers. Specifically the question concerns version 2.2 of SUN UNIX, but will no doubt extend to their later (and earlier) releases. The question follows; I have had occasion to use non-blocking sockets (TCP links) as a link across the Internet between 2 or more SUNs. Empirically, I have discovered that there is a limit of 2048 bytes which can be written in a single non-blocking write. Anything more than that and an error is returned "EMSGSIZE", which indicates that the internal buffer is only 2048 bytes. Note that if I use blocking sockets, the size is unlimited. There is also a limit of 4096 bytes total which can be held "in the pipe", before the receiving side of the socket must do a read to clear the internal buffers. In a Client/Server relationship, the server will read the bytes which the client writes into the socket. I've noticed that with non-blocking sockets where greater than 2K bytes can be written, that continuous calls to recv() or read() by the server will return 2K byte chunks. This leads me to believe that the SUN implementation can only handle a max of 2K byte transfers, and with only two of these before a read must be done. I've talked with SUN tech support and they tell me that this 'seems to be' the case, although without talking directly to an engineer I could not get a good idea of why this is. Finally, my question is this. Why is there a 2K limit, and can it be changed, perhaps with a kernal reconfiguration? It seems to me that putting such a limit on the sockets is a poor implementation for that layer, which should not restrict data size. Shouldn't such 'packetizing' be done at a lower layer than what sockets are the entry point to? Or are sockets actually a lower layer interface than I think? Any comments, pointers, or commiserations would be greatly appreciated. Robert Allen (415) 859-2143, robert@sri-spam.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606060122.AA26592%40bu-cs.bu.edu] <1986060517223200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: root@BU-CS.BU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: tcp on SUN computers. Message-ID: <8606060122.AA26592@bu-cs.bu.edu> Date: Thu, 5-Jun-86 21:22:32 EDT Article-I.D.: bu-cs.8606060122.AA26592 Posted: Thu Jun 5 21:22:32 1986 Date-Received: Fri, 6-Jun-86 20:20:27 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 52 Approved: tcp-ip@sri-nic.arpa There are two questions in your query, 1.> ...Finally, my question is this. Why is there a 2K limit, and >can it be changed, perhaps with a kernal reconfiguration? It almost certainly can be changed given sources, perhaps it can be changed otherwise or perhaps that is a suggestion that might be reasonable for binary sites. Perhaps for performance reasons it doesn't make sense to change this (what is a better number and why? Simply that it would make it easier for you to ignore the fact that you are doing non-blocking I/O is not a great reason.) 2.> It seems >to me that putting such a limit on the sockets is a poor implementation >for that layer, which should not restrict data size. Shouldn't >such 'packetizing' be done at a lower layer than what sockets are >the entry point to? Or are sockets actually a lower layer interface >than I think? This is a different question. Most importantly you state that this occurs only with non-blocking I/O. In the first place, this is not 'packetizing'. You provided 2K bytes and it received 2K bytes (and made it available to your consumer process.) The fact that they are both the same size is neither a coincidence nor a fault of the implementation. Something like packetizing might be implied had you read less than 2K and found the difference thrown off the floor (I guess, not sure there is any way this term can be worked into this conversation sensibly.) At some point a resource runs out, there is no way around that. On blocking (normal mode) I/O this results in a the process being blocked and waiting until resources are available. When you requested non-blocking I/O the system still had to do *something* when resources ran out (as I said, exactly how much of this resource should be allocated to a given process is an entirely different question.) What would you suggest it do? Ignore your I/O? Do it "anyhow"? Block you "anyhow"? I think it is doing the right thing (telling you immediately that I/O is not possible right now.) I think this was simply necessitated by allowing the user to specify non-blocking I/O, there is no fundamental difference between this and blocking I/O except the reason you felt it was "unlimited" in the latter case was only because the system took the responsibility for making you wait, as soon as you requested non-blocking I/O you stated that you wished to take that responsibility on yourself (ie. you probably had something else to do while waiting.) >Robert Allen -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606061052.AA02734%40ucbvax.Berkeley.EDU] <1986060518162300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mike@BRL.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: tcp on SUN computers. Message-ID: <8606061052.AA02734@ucbvax.Berkeley.EDU> Date: Thu, 5-Jun-86 22:16:23 EDT Article-I.D.: ucbvax.8606061052.AA02734 Posted: Thu Jun 5 22:16:23 1986 Date-Received: Fri, 6-Jun-86 20:34:28 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 27 Approved: tcp-ip@sri-nic.arpa Sockets themselves buffer a limited amount of data. The size of this socket buffering varries, depending on the type of socket (ie, pipe, TCP, UDP, etc). The system-wide default for TCP and UDP can be changed in 4.2 and 4.3 VAX UNIX systems by using ADB to poke the kernel variables tcp_sendspace and tcp_recvspace and udp_sendspace and udp_recvspace. These variables become parameters to the soreserve() routine each time a connection is opened. Note that in 4.2 the maximum size is 31k, in 4.3 it is 64k-1. These values are stored in the socket structure in SHORT ints; in 4.2 if the sign bit comes on, the world will break, thus the 31k limit rather than 32k or 64k-1. These variables can not casually be increased to LONG ints, because that would cause the socket struct not to fit into an MBUF, which is currently necessary, if a tad inelegant. 31k of buffering on each end is, in fact, quite reasonable. Also note that in 4.3 there is a parameter to the setsockopt() sys-call that can be used to adjust these values on a per-connection basis, rather than having to change the system-wide defaults. For those of you that have this, this is the preferred method of increasing buffering. I don't know at which SUN version the 4.3 capabilities will emerge, but almost certainly not in SUN 2.x (but I don't actually know). Best, -Mike Muuss ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986060518162301> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Thu 5 Jun 86 21:42:36-PDT Date: Thu, 5 Jun 86 22:16:23 EDT From: Mike Muuss To: Robert Allen cc: tcp-ip@sri-nic.arpa, unix-wizards@BRL.ARPA Subject: Re: tcp on SUN computers. Sockets themselves buffer a limited amount of data. The size of this socket buffering varries, depending on the type of socket (ie, pipe, TCP, UDP, etc). The system-wide default for TCP and UDP can be changed in 4.2 and 4.3 VAX UNIX systems by using ADB to poke the kernel variables tcp_sendspace and tcp_recvspace and udp_sendspace and udp_recvspace. These variables become parameters to the soreserve() routine each time a connection is opened. Note that in 4.2 the maximum size is 31k, in 4.3 it is 64k-1. These values are stored in the socket structure in SHORT ints; in 4.2 if the sign bit comes on, the world will break, thus the 31k limit rather than 32k or 64k-1. These variables can not casually be increased to LONG ints, because that would cause the socket struct not to fit into an MBUF, which is currently necessary, if a tad inelegant. 31k of buffering on each end is, in fact, quite reasonable. Also note that in 4.3 there is a parameter to the setsockopt() sys-call that can be used to adjust these values on a per-connection basis, rather than having to change the system-wide defaults. For those of you that have this, this is the preferred method of increasing buffering. I don't know at which SUN version the 4.3 capabilities will emerge, but almost certainly not in SUN 2.x (but I don't actually know). Best, -Mike Muuss ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12212582966.39.BLARSON%40USC-ECLB.ARPA] <1986060523215200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BLARSON@USC-ECLB.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: problems reaching cu20b Message-ID: <12212582966.39.BLARSON@USC-ECLB.ARPA> Date: Fri, 6-Jun-86 03:21:52 EDT Article-I.D.: USC-ECLB.12212582966.39.BLARSON Posted: Fri Jun 6 03:21:52 1986 Date-Received: Fri, 6-Jun-86 20:28:02 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa I frequently have problems trying to get files from cu20b.columbia.edu using ftp from either usc-eclb.arpa (milnet) or usc-oberon.arpa (arpanet). Tops-20 ftp (usc-eclb.arpa) gives the message "connection rejected for unknown reason" and 4.2bsd ftp (usc-oberon.arpa) gives the message "network unreachable". (This is the second night in a row this week, and I have had similar problems before.) I have also had many mail messages returned with "system unreachable" after three days through both usc-ecl.arpa (milnet) and usc-eclc.arpa. (arpanet) (both Tops-20) Apparently cu20b.columbia.edu (also a tops-20 machine) has no problems sending mail to us, we get the info-kermit digest regularly. Neither the local postmaster or the info-kermit people seem to know a reason for this problem. Where is the proper place to report this type of problem? Are other people experiencing it to? Mail can be gotten through by routing via other systems. (I used to use columbia.arpa, but it no longer understands the % hack and I haven't figured out out to specify an @host1:user@host2 address to tops-20 mm.) For ftp, I just keep trying until it decides to work. Bob Larson ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986060600533900> Received: from SRI-CSL.ARPA by SRI-NIC.ARPA with TCP; Fri 6 Jun 86 07:54:00-PDT Date: Fri 6 Jun 86 07:53:39-PDT From: Karl Auerbach Subject: Re: tcp on SUN computers. To: robert@SRI-SPAM.ARPA cc: tcp-ip@SRI-NIC.ARPA, AUERBACH@SRI-CSL.ARPA In-Reply-To: Message from "Robert Allen " of Thu 5 Jun 86 21:34:28-PDT This may be incorrect, but I have heard that 4.2/4.3 based TCP implementations set the push flag for every user write. This somewhat transforms the TCP stream into packets as viewed by the receiver. I'm sure someone out there knows whether this is true or not. --karl-- (Karl Auerbach, Epilogue Technology Corp.) auerbach@sri-csl.arpa ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606061624.AA07072%40ucbvax.Berkeley.EDU] <1986060606533900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: AUERBACH@SRI-CSL.ARPA (Karl Auerbach) Newsgroups: mod.protocols.tcp-ip Subject: Re: tcp on SUN computers. Message-ID: <8606061624.AA07072@ucbvax.Berkeley.EDU> Date: Fri, 6-Jun-86 10:53:39 EDT Article-I.D.: ucbvax.8606061624.AA07072 Posted: Fri Jun 6 10:53:39 1986 Date-Received: Fri, 6-Jun-86 23:42:48 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa This may be incorrect, but I have heard that 4.2/4.3 based TCP implementations set the push flag for every user write. This somewhat transforms the TCP stream into packets as viewed by the receiver. I'm sure someone out there knows whether this is true or not. --karl-- (Karl Auerbach, Epilogue Technology Corp.) auerbach@sri-csl.arpa ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606061733.AA03794%40ucbopal.Berkeley.Edu] <1986060609335900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: minshall%ucbopal@UCBVAX.BERKELEY.EDU (Greg Minshall) Newsgroups: mod.protocols.tcp-ip Subject: Re: tn3270 Message-ID: <8606061733.AA03794@ucbopal.Berkeley.Edu> Date: Fri, 6-Jun-86 13:33:59 EDT Article-I.D.: ucbopal.8606061733.AA03794 Posted: Fri Jun 6 13:33:59 1986 Date-Received: Fri, 6-Jun-86 23:49:30 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa Dave, You can do an anonymous ftp to ucbarpa, cwd to pub, and pick up tn3270tar. This version is as of last December, but I only know of one change since then (and it wasn't major). I'm currently working on a PC version, but maybe I will be able to stop for a bit and package up the current version for you. Greg ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606061834.AA00127%40sluggo.sun.uucp] <1986060610343200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: melohn%sluggo@SUN.COM (Bill Melohn) Newsgroups: mod.protocols.tcp-ip Subject: Re: problems reaching cu20b Message-ID: <8606061834.AA00127@sluggo.sun.uucp> Date: Fri, 6-Jun-86 14:34:32 EDT Article-I.D.: sluggo.8606061834.AA00127 Posted: Fri Jun 6 14:34:32 1986 Date-Received: Fri, 6-Jun-86 23:50:21 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa Chances are good that the network which cu20b is on has fallen out of the limited size EGP reachablity table that you (or more likely your core gateway) use. This appears to happen to our non-backbone network every once in a while. The solution is to get more powerful core gateways that implement EGP and provide more space for the ever increasing numbers of non-backbone internet networks. If access to cu20b is really important to your site, you might consider adding the entry for the columbia gateway to ECLx's INTERNET.GATEWAYS file. That way you will not have to ask your core gateway how to get to cu20b. Bill ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606070419.AA06179%40ucbvax.Berkeley.EDU] <1986060620204200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mills@DCN6.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Here's clocking at you Message-ID: <8606070419.AA06179@ucbvax.Berkeley.EDU> Date: Sat, 7-Jun-86 00:20:42 EDT Article-I.D.: ucbvax.8606070419.AA06179 Posted: Sat Jun 7 00:20:42 1986 Date-Received: Sat, 7-Jun-86 13:37:24 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 29 Approved: tcp-ip@sri-nic.arpa Folks, I know this must be Summer because our radio clocks are drowning in ionspheric ooze, which sloshes deeper as the days grow long. Yesterday our WWVB clock on popular fuzzball timeteller DCN1.ARPA picked up a hot bit which added 256 days to the day of year and turned its timecode-conversion routine into a hash function. The resulting random bits presented to timecallers broke a bunch of code scattered all over the Internet, or at least that's what I concluded once the phones stopped ringing. When I manually disabled the broken clock, our clever backup algorithm, put in last year at this time when the ions grew dim, promptly chose the WWV clock on DCN6.ARPA. But that was bust too, so the algorithm chose as the next backup the GOES clock on FORD1.ARPA and finally got it right. It turns out this sequence of events is not uncommon at this time of year; however, before you pull your clock plugs, be advised there are two more backups, the WWVB clock on UMD1.ARPA and the WWV clock on GW.UMICH.EDU. I guess you could say we have a magnificent, redundant algorithm which reliably delivers the wrong time. This latest problem should not recur, since I sloshed ample bugspray on the conversion routine to nip blatant timecode lies, but little lies (like the wrong year) are known from experience to be just as bad. Therefore, I sieze the opportunity first to apologize for all those broken message timestamps, file dates and accounting programs that bogged yesterday and then to appeal for more players of the Network Time Protocol (RFC-958) game, which may be the best polygraph. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986060703563700> Received: from DCN6.ARPA by SRI-NIC.ARPA with TCP; Fri 6 Jun 86 20:56:57-PDT Date: 07-Jun-86 03:56:37-UT From: mills@dcn6.arpa Subject: Here's clocking at you To: tcp-ip@sri-nic.arpa Folks, I know this must be Summer because our radio clocks are drowning in ionspheric ooze, which sloshes deeper as the days grow long. Yesterday our WWVB clock on popular fuzzball timeteller DCN1.ARPA picked up a hot bit which added 256 days to the day of year and turned its timecode-conversion routine into a hash function. The resulting random bits presented to timecallers broke a bunch of code scattered all over the Internet, or at least that's what I concluded once the phones stopped ringing. When I manually disabled the broken clock, our clever backup algorithm, put in last year at this time when the ions grew dim, promptly chose the WWV clock on DCN6.ARPA. But that was bust too, so the algorithm chose as the next backup the GOES clock on FORD1.ARPA and finally got it right. It turns out this sequence of events is not uncommon at this time of year; however, before you pull your clock plugs, be advised there are two more backups, the WWVB clock on UMD1.ARPA and the WWV clock on GW.UMICH.EDU. I guess you could say we have a magnificent, redundant algorithm which reliably delivers the wrong time. This latest problem should not recur, since I sloshed ample bugspray on the conversion routine to nip blatant timecode lies, but little lies (like the wrong year) are known from experience to be just as bad. Therefore, I sieze the opportunity first to apologize for all those broken message timestamps, file dates and accounting programs that bogged yesterday and then to appeal for more players of the Network Time Protocol (RFC-958) game, which may be the best polygraph. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986060816034300> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Sun 8 Jun 86 23:07:05-PDT Date: 8 Jun 1986 23:03:43 PDT Subject: Re: tcp on SUN computers. From: Stephen Casner To: Mike Muuss cc: Robert Allen , tcp-ip@SRI-NIC.ARPA, unix-wizards@BRL.ARPA, Casner@USC-ISIB.ARPA In-Reply-To: (Message from "Mike Muuss " of Thu, 5 Jun 86 22:16:23 EDT) I have found that with Sun release 2.0 "the world will break" if I patch tcp_sendspace and tcp_recvspace to be only 16K, not 32K. At 15K it works, but 16K crashes. I would like very much to get up to 31K because we need that much for efficient use of the Wideband Satellite Network. Any clue as to how I might get there? -- Steve Casner ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606090625.AA04218%40ucbvax.Berkeley.EDU] <1986060822034300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Casner@USC-ISIB.ARPA (Stephen Casner) Newsgroups: mod.protocols.tcp-ip Subject: Re: tcp on SUN computers. Message-ID: <8606090625.AA04218@ucbvax.Berkeley.EDU> Date: Mon, 9-Jun-86 02:03:43 EDT Article-I.D.: ucbvax.8606090625.AA04218 Posted: Mon Jun 9 02:03:43 1986 Date-Received: Mon, 9-Jun-86 17:17:02 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa I have found that with Sun release 2.0 "the world will break" if I patch tcp_sendspace and tcp_recvspace to be only 16K, not 32K. At 15K it works, but 16K crashes. I would like very much to get up to 31K because we need that much for efficient use of the Wideband Satellite Network. Any clue as to how I might get there? -- Steve Casner ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986061006012800> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Tue 10 Jun 86 13:03:32-PDT Date: 10 Jun 1986 13:01:28 PDT Subject: Re: tcp on SUN computers. From: Stephen Casner To: nowicki%rose@SUN.COM (Bill Nowicki) cc: Casner@USC-ISIB.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: <8606101851.AA03868@rose.sun.uucp> I borrowed the quote about the world breaking from Mike Muuss. What I meant by it was that with tcp_sendspace and tcp_recvspace patched to 16K in a 2.0 kernel, the system crashed during the process of booting. I don't remember the details of the crash, but I believe it was a panic or the like. I'd like very much to have my machine upgraded to 3.x, but first we have to buy more memory => more swap space => no user file space => more NFS space... -- Steve Casner ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606101851.AA03868%40rose.sun.uucp] <1986061010510200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: nowicki%rose@SUN.COM (Bill Nowicki) Newsgroups: mod.protocols.tcp-ip Subject: Re: tcp on SUN computers. Message-ID: <8606101851.AA03868@rose.sun.uucp> Date: Tue, 10-Jun-86 14:51:02 EDT Article-I.D.: rose.8606101851.AA03868 Posted: Tue Jun 10 14:51:02 1986 Date-Received: Tue, 10-Jun-86 22:53:40 EDT Sender: carvalho@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa I have found that with Sun release 2.0 "the world will break" if I patch tcp_sendspace and tcp_recvspace to be only 16K, not 32K. At 15K it works, but 16K crashes. Please clarify what you mean by "world will break". Last week I did some tests and tried various sizes like 16K and 32K without any "crashes". There is a severe performance problem if one side has a large recvspace and the other has a sendspace that is less than or equal to one quarter of the recvspace. The "silly window syndrome avoidance feature" then takes effect, and you can send only five times the sendspace per second. For example, if a machine with increased recvspace (8K) sends to a machine with the default sendspace of 2K, then throghput is 10Kbytes/second, about twenty times slower than 2K sending to 2K! This is probably true for 4.2 in general, but have not tried the 4.3BSD SWSA code. Note that my experiments are using Sun-3s running 3.x -- you should upgrade from 2.x as soon as you can, since 3.x has several of the 4.2BSD bugs removed. -- Bill Nowicki Sun Micsrosystems ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606102124.AA08776%40ucbvax.Berkeley.EDU] <1986061012012800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Casner@USC-ISIB.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: tcp on SUN computers. Message-ID: <8606102124.AA08776@ucbvax.Berkeley.EDU> Date: Tue, 10-Jun-86 16:01:28 EDT Article-I.D.: ucbvax.8606102124.AA08776 Posted: Tue Jun 10 16:01:28 1986 Date-Received: Tue, 10-Jun-86 23:59:56 EDT References: <8606101851.AA03868@rose.sun.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa I borrowed the quote about the world breaking from Mike Muuss. What I meant by it was that with tcp_sendspace and tcp_recvspace patched to 16K in a 2.0 kernel, the system crashed during the process of booting. I don't remember the details of the crash, but I believe it was a panic or the like. I'd like very much to have my machine upgraded to 3.x, but first we have to buy more memory => more swap space => no user file space => more NFS space... -- Steve Casner ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606102247.AA07738%40oddjob] <1986061014473000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: matt@oddjob.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: more interesting features of 4.2 Message-ID: <8606102247.AA07738@oddjob> Date: Tue, 10-Jun-86 18:47:30 EDT Article-I.D.: oddjob.8606102247.AA07738 Posted: Tue Jun 10 18:47:30 1986 Date-Received: Wed, 11-Jun-86 18:58:31 EDT References: <12211785351.33.HEDRICK@RED.RUTGERS.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "Matt Crawford" Organization: The ARPA Internet Lines: 30 Approved: tcp-ip@sri-nic.arpa It turns out that you can specify routing entries that will cause a host to treat destinations on that network as local. I.e. it will issue ARP's for them, just as if they were on the local Ethernet. The correct form is route add 0 if you want to set this up as a default. I tried "route add usan-net oddjob 0" some time ago, trying to access the USAN satellite net through our VitaLink box. This works to NCAR (where all hosts' addresses are on usan-net) if they do the corresponding operation on their end. The trouble comes when you want to specify that a host on the other net is a gateway to yet another net. The route-adding code insists that you can't do it. I then wrote a pseudo-interface driver which claims an interface address of "oddjob" (192.5.73.2) but a broadcast address of "usan-net" (192.17.4.0). This works OK (I'm still using it), but still has some drawbacks. One is that the other end (U of I at Urbana in this case) would have to put up a similar pseudo- interface on their gateway to usan-net before their networks and our networks are fully connected. Another is that broadcasts such as RIP packets sent to usan-net generate ICMP messages from other hosts on the local net here. I don't think any arrangement will really work satisfactorily if it has bridges connecting nets with different IP numbers. Matt Crawford ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606111350.AA22295%40ucbvax.Berkeley.EDU] <1986061105111000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: louden@MITRE-GATEWAY.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: RFC 986 Questions Message-ID: <8606111350.AA22295@ucbvax.Berkeley.EDU> Date: Wed, 11-Jun-86 09:11:10 EDT Article-I.D.: ucbvax.8606111350.AA22295 Posted: Wed Jun 11 09:11:10 1986 Date-Received: Wed, 11-Jun-86 19:11:57 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa I have a few questions about RFC 986. First, I have a LAN that is both connected to a PDN and the ARPANET. Which addressing method do I use? Second, what does TCP do for a pseudo header (It contains the IP addresses) when there are no IP address in X.121 across a PDN? This may be a can of worms better addressed by saying you use all ISO or all DoD but not both mixed. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986061105111001> Received: from mitre-gateway.arpa by SRI-NIC.ARPA with TCP; Wed 11 Jun 86 06:25:08-PDT Date: 11 Jun 1986 9:11:10 EDT (Wednesday) From: T. Michael Louden (MS W422) Subject: RFC 986 Questions To: tcp-ip@SRI-NIC.ARPA Cc: louden@mitre-gateway I have a few questions about RFC 986. First, I have a LAN that is both connected to a PDN and the ARPANET. Which addressing method do I use? Second, what does TCP do for a pseudo header (It contains the IP addresses) when there are no IP address in X.121 across a PDN? This may be a can of worms better addressed by saying you use all ISO or all DoD but not both mixed. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606111507.AA23246%40ucbvax.Berkeley.EDU] <1986061106344900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: MILLS@USC-ISID.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: more interesting features of 4.2 Message-ID: <8606111507.AA23246@ucbvax.Berkeley.EDU> Date: Wed, 11-Jun-86 10:34:49 EDT Article-I.D.: ucbvax.8606111507.AA23246 Posted: Wed Jun 11 10:34:49 1986 Date-Received: Wed, 11-Jun-86 22:11:16 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 Approved: tcp-ip@sri-nic.arpa In response to the message sent Tue, 10 Jun 86 17:47:30 cdt from "Matt Crawford" Matt, USAN (192.17.4) is currently gatewayed to ARPANET via a fuzzball at U Michigan on an experimental basis. The fuzzball gateway is gimmicked with an incredible routing algorithm that provides connectivity for all the j-random networks babbling on the USAN channel, as well as many other networks that seem to be passing by from time to time. The gimmicks include "promiscuous" ARP, dynamic logical-address translation and multiple delay-based routing algorithms sharing the same cable. While the experiment is somewhat of a lashup at present, the experience gained seems to indicate that it would be practical to evolve a working standard for multiplexing broadcast channels with arbitrary routing plexes. Whether you want to do that on a performance basis may be another matter. The experience with showers of redirects and unreachables in this environment was what led to my suggestion a few days back on a standard filtering algorithm for Internet gateways. Hans-Werner Braun (hwb@gw-umich.edu) did most of the brain-punishing work in evolving the techniques and making the fuzzball gateway play on USAN. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12213994256.57.HEDRICK%40RED.RUTGERS.EDU] <1986061108341800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: how to handle Vitalink networks Message-ID: <12213994256.57.HEDRICK@RED.RUTGERS.EDU> Date: Wed, 11-Jun-86 12:34:18 EDT Article-I.D.: RED.12213994256.57.HEDRICK Posted: Wed Jun 11 12:34:18 1986 Date-Received: Wed, 11-Jun-86 22:17:23 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa We have an equivalent of your Vitalink network, using Applitek bridges. We make sure that one gateways off that network does "promiscuous ARP". This is a generalization of the "ARP hack" that has long been used for subnetting. It generalizes it by having the gateways accept an ARP for absolutely any address at all. If they are the appropriate gateway, they respond with their Ethernet address. If not, they respond with the Ethernet address of the correct gateway. (If you have several gateways that do this, you can modify the code so that a gateway does not respond for another gateway if the second is known to be capable of responding for itself.) This is the ARP equivalent of an ICMP redirect. Note that you only need one such gateway on a network, since it can hand out the Ethernet addresses of the other gateways. This is the only technique we can think of that can handle complex networks built with systems like the Vitalink and Applitek. (I do not approve of such bridges, but I can't prevent people from buying them, so I've had to come up with a way to live with them.) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606112123.AA02771%40nprdc.arpa] <1986061113230000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: stanonik@NPRDC.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: 4.3bsd/subnetting Message-ID: <8606112123.AA02771@nprdc.arpa> Date: Wed, 11-Jun-86 17:23:00 EDT Article-I.D.: nprdc.8606112123.AA02771 Posted: Wed Jun 11 17:23:00 1986 Date-Received: Thu, 12-Jun-86 03:30:06 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 Approved: tcp-ip@sri-nic.arpa Now that subnetting (and subnet arp support) is available, some questions arise about using it, particularly about making the transition to subnets. The local network (class B) currently consists of a main cable to which every host is directly attached. Because subnetting was anticipated, addresses were assigned in a subnet fashion; ie, the third byte (intended to become the subnet number) grouped machines. That however seems to cause a problem for the transition to subnets. To any subnet branching off the main cable, the addresses of those not yet capable of subnetting make the main cable look like a collection of subnets. Yuck! 4.3bsd doesn't seem to allow more than one subnet per interface (cable), so many of those hosts will be unreachable. A nice(?) solution would be to continue to treat the main cable as unsubnetted (netmask 0xffff0000) and only route to it packets not bound for known subnets, but 4.3bsd doesn't seem to do this. Have we overlooked some routing trick, or must everyone remaining on the main cable change addresses to one subnet number? Thanks, Ron Stanonik stanonik@nprdc.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606120327.AA03310%40ucbvax.Berkeley.EDU] <1986061118465600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mike@BRL.ARPA (Mike Muuss) Newsgroups: mod.protocols.tcp-ip Subject: Re: tcp on SUN computers. Message-ID: <8606120327.AA03310@ucbvax.Berkeley.EDU> Date: Wed, 11-Jun-86 22:46:56 EDT Article-I.D.: ucbvax.8606120327.AA03310 Posted: Wed Jun 11 22:46:56 1986 Date-Received: Thu, 12-Jun-86 18:39:29 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 3 Approved: tcp-ip@sri-nic.arpa Well, I guess for SUN 2.0, the magic number must be 16k-1. At least this is an improvement :-) -M ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986061118465601> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Wed 11 Jun 86 19:49:46-PDT Date: Wed, 11 Jun 86 22:46:56 EDT From: Mike Muuss To: Stephen Casner cc: Mike Muuss , Robert Allen , tcp-ip@sri-nic.arpa, unix-wizards@BRL.ARPA, Casner@usc-isib.arpa Subject: Re: tcp on SUN computers. Well, I guess for SUN 2.0, the magic number must be 16k-1. At least this is an improvement :-) -M ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606120220.AA02623%40ucbvax.Berkeley.EDU] <1986061118503800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hwb@GW.UMICH.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: RFC986 questions Message-ID: <8606120220.AA02623@ucbvax.Berkeley.EDU> Date: Wed, 11-Jun-86 22:50:38 EDT Article-I.D.: ucbvax.8606120220.AA02623 Posted: Wed Jun 11 22:50:38 1986 Date-Received: Thu, 12-Jun-86 03:21:04 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 37 Approved: tcp-ip@sri-nic.arpa Let me make a few comments about some of the reasons behind RFC986. The question of mixing or not mixing protocols is an important one, though not really, or at least only to some extend, the issue here. What needs to be accomplished is that existing network backbones can be utilized for ISO protocols, which includes the ISO CLNS. It probably does not make too much sense to have, e.g., an Arpanet and an ISO-Arpanet existing and being disjoint at the same time. Not even on an iterim base. It therefore becomes necessary to utilize existing backbones (good examples here are the Arpanet and the upcoming NSFnet) for both protocol suites, especially since these suites do not differ that much from each other anyway. RFC985 points out quite nicely that Ethernets are some kind of lowest common denominator to which most hosts can connect. We can probably safely assume that most gateways drop their traffic onto a local Ethernet. If, e.g., two gateways, which are attached to the Arpanet would talk both IP and the ISO-CLNS, while eventually utilizing the same routing data base local to the gateway, people could talk the ISO-CLNS accross the country. It would not matter at all what runs on top of ISOgrams in this case. Further routing through subsequent gateways within the local net would obviously be a local issue here. These (sub)gateways would have to understand both 'gram protocols, too, and, e.g., could distinguish between them according to different Ethernet type fields seen on the Ethernet. RFC986 is a draft only and probably needs further refinements so that and Internet standard could emerge which could be given to the implementors of gateways. Suggestions for these refinements would be welcome. A small committee chaired by Phil Gross (Mitre) was furthermore tasked with coming up with suggestions for possible scenarios for RFC986, which will (hopefully) result in a subsequent RFC. Input for this would be appreciated, too. -- Hans-Werner ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12214109227.9.JNC%40XX.LCS.MIT.EDU] <1986061119055200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa") Newsgroups: mod.protocols.tcp-ip Subject: Re: 4.3bsd/subnetting Message-ID: <12214109227.9.JNC@XX.LCS.MIT.EDU> Date: Wed, 11-Jun-86 23:05:52 EDT Article-I.D.: XX.12214109227.9.JNC Posted: Wed Jun 11 23:05:52 1986 Date-Received: Thu, 12-Jun-86 19:11:08 EDT References: <8606112123.AA02771@nprdc.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa I don't think there's any easy way to do this if you can't make your 4.3 gateway accept more than one IP address for a single interface. I guess you've considered the obvious brute-force solutions like putting N different interfaces in your gateway machine, or getting another class B network and making that the subnetted net. Being able to assign a single physical net several logical net numbers makes renumbering things really painless; you don't have to have a massive flag day. That's such a useful capability for a gateway to have that I'm surprised 4.3 is missing it; are you sure there's no way to do it? Maybe someone should or has added it to 4.3. Of course, the difficulty factor of doing this will really depend on how the insides of the 4.3 IP layer are arranged. I can tell you from experience in the C Gateway that some places you really have to work at it to make things work with multiple addresses per interface. Consider sending out routing packets (you can't use the all 1's broadcast address since people may get routing packets intended for the other logical net), checking for incoming broadcast packets, etc! Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986061201300800> Received: from GW.UMICH.EDU by SRI-NIC.ARPA with TCP; Wed 11 Jun 86 18:32:39-PDT Date: 12-Jun-86 01:30:08-UT From: hwb@gw.umich.edu Subject: Re: RFC986 questions To: Louden@Mitre-Gateway.ARPA cc: TCP-IP@SRI-NIC.ARPA, HWB@GW.UMICH.EDU Let me make a few comments about some of the reasons behind RFC986. The question of mixing or not mixing protocols is an important one, though not really, or at least only to some extend, the issue here. What needs to be accomplished is that existing network backbones can be utilized for ISO protocols, which includes the ISO CLNS. It probably does not make too much sense to have, e.g., an Arpanet and an ISO-Arpanet existing and being disjoint at the same time. Not even on an iterim base. It therefore becomes necessary to utilize existing backbones (good examples here are the Arpanet and the upcoming NSFnet) for both protocol suites, especially since these suites do not differ that much from each other anyway. RFC985 points out quite nicely that Ethernets are some kind of lowest common denominator to which most hosts can connect. We can probably safely assume that most gateways drop their traffic onto a local Ethernet. If, e.g., two gateways, which are attached to the Arpanet would talk both IP and the ISO-CLNS, while eventually utilizing the same routing data base local to the gateway, people could talk the ISO-CLNS accross the country. It would not matter at all what runs on top of ISOgrams in this case. Further routing through subsequent gateways within the local net would obviously be a local issue here. These (sub)gateways would have to understand both 'gram protocols, too, and, e.g., could distinguish between them according to different Ethernet type fields seen on the Ethernet. RFC986 is a draft only and probably needs further refinements so that and Internet standard could emerge which could be given to the implementors of gateways. Suggestions for these refinements would be welcome. A small committee chaired by Phil Gross (Mitre) was furthermore tasked with coming up with suggestions for possible scenarios for RFC986, which will (hopefully) result in a subsequent RFC. Input for this would be appreciated, too. -- Hans-Werner ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606121253.AA11410%40ucbvax.Berkeley.EDU] <1986061204101700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: louden@MITRE-GATEWAY.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: RFC986 questions Message-ID: <8606121253.AA11410@ucbvax.Berkeley.EDU> Date: Thu, 12-Jun-86 08:10:17 EDT Article-I.D.: ucbvax.8606121253.AA11410 Posted: Thu Jun 12 08:10:17 1986 Date-Received: Thu, 12-Jun-86 19:28:18 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 31 Approved: tcp-ip@sri-nic.arpa If the goal is to allow both ISO and DoD on the ARPANET, why not use the same link level and different net levels? This would be compatable with both protocols since X.25 is in both. Connecting the two worlds can then be done at the applications level by application gateways that understand what is needed, such as X.400 to SMTP. The issue of gateways can be handled by implementing both DoD and ISO net level protocols and selecting the one that makes sense for a packet, such as checking version number is correct. This method works in a well defined way (all the protocols are spec.ed) and does not require the large development effort to be wasted on a tempory patch until a complete transition is made. Note that changing to ISO net layer requires all hosts to modify their software even if they will be replaced before the network converts fully to ISO. Dual mode operation would only require gateways connection dual mode networks to be modified. This sounds cheeper to me. To my knowledge there are at least 3 organizations working on this solution. The largest and best funded is the NBS effort to develop a standard application gateway. This has been discussed at the NBS ISO workshops. ... Sorry I cannot reply directly to you because we are using a BBN C70 with the standard release software. This does not support domain addresses other than .ARPA. BBN says they will fix as soon as they can but it is an example of the problems in requiring a conversion in existing protocols. It sometimes takes more time and money than you have. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986061204101701> Received: from mitre-gateway.arpa by SRI-NIC.ARPA with TCP; Thu 12 Jun 86 05:24:58-PDT Date: 12 Jun 1986 8:10:17 EDT (Thursday) From: T. Michael Louden (MS W422) Subject: Re: RFC986 questions In-Reply-to: Your message of 12-Jun-86 01:30:08-UT To: louden@mitre-gateway.arpa Cc: tcp-ip@SRI-NIC.ARPA, louden@MITRE If the goal is to allow both ISO and DoD on the ARPANET, why not use the same link level and different net levels? This would be compatable with both protocols since X.25 is in both. Connecting the two worlds can then be done at the applications level by application gateways that understand what is needed, such as X.400 to SMTP. The issue of gateways can be handled by implementing both DoD and ISO net level protocols and selecting the one that makes sense for a packet, such as checking version number is correct. This method works in a well defined way (all the protocols are spec.ed) and does not require the large development effort to be wasted on a tempory patch until a complete transition is made. Note that changing to ISO net layer requires all hosts to modify their software even if they will be replaced before the network converts fully to ISO. Dual mode operation would only require gateways connection dual mode networks to be modified. This sounds cheeper to me. To my knowledge there are at least 3 organizations working on this solution. The largest and best funded is the NBS effort to develop a standard application gateway. This has been discussed at the NBS ISO workshops. ... Sorry I cannot reply directly to you because we are using a BBN C70 with the standard release software. This does not support domain addresses other than .ARPA. BBN says they will fix as soon as they can but it is an example of the problems in requiring a conversion in existing protocols. It sometimes takes more time and money than you have. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606121452.AA12800%40ucbvax.Berkeley.EDU] <1986061206535300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: hwb@GW.UMICH.EDU Newsgroups: mod.protocols.tcp-ip Subject: Re: RFC986 questions Message-ID: <8606121452.AA12800@ucbvax.Berkeley.EDU> Date: Thu, 12-Jun-86 10:53:53 EDT Article-I.D.: ucbvax.8606121452.AA12800 Posted: Thu Jun 12 10:53:53 1986 Date-Received: Fri, 13-Jun-86 00:43:59 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa I think we are really talking about the same thing (utilizing the same link layer). Please re-read my previous message. The issue here is *routing* and not so much how protocols get used. The need for application gateways for the interim is definitely implied in here. -- Hans-Werner PS: NBS and ISO folks (among others) reviewed the RFC986 before it got published. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MS.leong.0.leong.110.20%40andrew.cmu.edu] <1986061208511400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: leong@PO1.ANDREW.CMU.EDU (John Leong) Newsgroups: mod.protocols.tcp-ip Subject: rfc983 Message-ID: Date: Thu, 12-Jun-86 12:51:14 EDT Article-I.D.: andrew.MS.leong.0.leong.110.20 Posted: Thu Jun 12 12:51:14 1986 Date-Received: Fri, 13-Jun-86 00:44:23 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 46 Approved: tcp-ip@sri-nic.arpa Having been involved with the ISO Transport Protocol definition a few years ago (started when it still an ECMA draft spec and a very very prelimary draft ISO spec from the Tokyo or was it Berlin meeting), it was very interesting to read the RFC983 "ISO Transport Services on Top of the TCP". I am afraid the RFC is very much NOT in the spirite of things. Every (newer) ISO protocol specification must be accompanied by a service specification. The primitives defined in the service specification is intended solely for explaination of the service offered by the protocol. Like the OSI reference model (from which it is derived), it is not an implementation guide. Furthermore, the primitives defines LOCAL INTERFACE and not PROTOCOL. Actually if you look at protocols for every layer, (e.g. Session) the service primitives and terminology (straight out of OSI) such as SAP's looks virtually identical. The actual service implementation at the interface is very dependent on the local operating system environment. Hence Connection Request, Connection Confirmation, Connection Indication etc. are manifested differently in an UNIX 4.2 socket environment from that of an VMS-VAX or whatever other operating system environment. It is definitely not the intent to have the primivites encoded and transported in a peer-to-peer fashion as a protocol. In that case, a service specification have to be defined for this "new" protocol and we quickly get into a recursion-with-no-exit situation!!! In general, it is important for one to produce good generic protocol interface design so that a particluar protocol implementation or even the protocol itself can easily be replaced without affecting the code in the upper or lower layer. A well designed generic interface can be used for every layer although the data structure associated with a primitive will most likely to be different. The UNIX 4.2 socket mechanism is a good start. One final note, for people who is really interested in implementation of the Transport and Session Protocols, the best set of documentation I have seen (besides the offical specification) can be obtained from : National Bureau of Standards, @* Institute for Computer Sciences and Technology, @* Center for Computer Systems Engineering, @* Systems and NetworkArchitecture Division The set is produced under contract by BBN back in 1980/81. It contains service specification, protocol specification, as well as implementation guide including wonderful pseudo codes. While the Transport Protocol spec is not 100% ISO spec, it is 99% close. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606122211.AA19218%40ucbvax.Berkeley.EDU] <1986061212382800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: louden@MITRE-GATEWAY.ARPA (T. Michael Louden, MS W422) Newsgroups: mod.protocols.tcp-ip Subject: RE: RFC986 Questions Message-ID: <8606122211.AA19218@ucbvax.Berkeley.EDU> Date: Thu, 12-Jun-86 16:38:28 EDT Article-I.D.: ucbvax.8606122211.AA19218 Posted: Thu Jun 12 16:38:28 1986 Date-Received: Fri, 13-Jun-86 00:46:04 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 2 Approved: tcp-ip@sri-nic.arpa So the RFC is for addressing in an ISO stack on the ARPA style net. That makes more sense to me. Thanks for the clearification! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986061212382801> Received: from mitre-gateway.arpa by SRI-NIC.ARPA with TCP; Thu 12 Jun 86 13:45:57-PDT Date: 12 Jun 1986 16:38:28 EDT (Thursday) From: T. Michael Louden (MS W422) Subject: RE: RFC986 Questions To: tcp-ip@SRI-NIC.ARPA Cc: louden@mitre-gateway.arpa So the RFC is for addressing in an ISO stack on the ARPA style net. That makes more sense to me. Thanks for the clearification! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986061214013100> Received: from GW.UMICH.EDU by SRI-NIC.ARPA with TCP; Thu 12 Jun 86 07:08:03-PDT Date: 12-Jun-86 14:01:31-UT From: hwb@gw.umich.edu Subject: Re: RFC986 questions To: louden@mitre-gateway.arpa cc: tcp-ip@sri-nic.arpa, hwb@GW.UMICH.EDU I think we are really talking about the same thing (utilizing the same link layer). Please re-read my previous message. The issue here is *routing* and not so much how protocols get used. The need for application gateways for the interim is definitely implied in here. -- Hans-Werner PS: NBS and ISO folks (among others) reviewed the RFC986 before it got published. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [20148.518994237%40nrtc-gremlin.northrop.com] <1986061217032200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mrose@nrtc-gremlin.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: rfc983 Message-ID: <20148.518994237@nrtc-gremlin.northrop.com> Date: Thu, 12-Jun-86 21:03:22 EDT Article-I.D.: nrtc-gre.20148.518994237 Posted: Thu Jun 12 21:03:22 1986 Date-Received: Fri, 13-Jun-86 06:41:22 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 41 Approved: tcp-ip@sri-nic.arpa As one of the authors of the RFC, I feel I should clear up some misconceptions you have regarding it. At no point in rfc983 is it said how to implement the interface to the TSAP. What is said is how you can build such an interface on top of the TCP. That is, given the abstract service definitions for the TP, instructions are given as to how one can map those onto the services provided by the TCP. From our perspective, a proper implementation of rfc983 exhibits the following properties: - it has the TSAP interface that you want on your host - it uses the protocol defined in the rfc We have such an implementation for Berkeley 4.2 UNIX. I imagine that an implementation for TOPS-20 would look entirely different, both in actual internal code (the protocol engine) and in the interface code (subroutine library). The same goes for VAX/VMS, obviously. But, they would all speak the same protocol (as defined in rfc983). Perhaps the problem here, is that it appears to you that rfc983 specifies an "ISO protocol". This is certainly not our intention. the rfc specifies a DDN-style protocol which provides ISO services. It is the intent of rfc983 to permit standard ISO protocols to run on top of the TCP. It is not the intent to build ISO-like protocols for the ARPA Internet. I completely agree with your statement that: "In general, it is important for one to produce good generic protocol interface design so that a particular protocol implementation or even the protocol itself can easily be replaced without affecting the code in the upper or lower layer." But I fail to see how rfc983 violates this concern. Quite the contrary: rfc983 rips out the ISO TP internals and substitutes calls to the services provided by the TCP! /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606150302.AA19984%40phri.UUCP] <1986061419024600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: roy@phri.UUCP (Roy Smith) Newsgroups: mod.protocols.tcp-ip Subject: Fuzzball hosts Message-ID: <8606150302.AA19984@phri.UUCP> Date: Sat, 14-Jun-86 23:02:46 EDT Article-I.D.: phri.8606150302.AA19984 Posted: Sat Jun 14 23:02:46 1986 Date-Received: Wed, 18-Jun-86 03:11:46 EDT Sender: daemon@styx.UUCP Reply-To: phri!roy@seismo.css.gov (Roy Smith) Distribution: mod Organization: Public Health Research Inst. (NY, NY) Lines: 5 Approved: tcp-ip@sri-nic.arpa Sorry if this is a naive question, but exectly what is a "fuzzball host"? I've seen the term any number of times, but it's never quite been made clear what it is. Does it mean something specific, or is it just a general derogatory term? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860615162744.2.DCP%40FIREBIRD.SCRC.Symbolics.COM] <1986061512270000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@SCRC-QUABBIN.ARPA (David C. Plummer) Newsgroups: mod.protocols.tcp-ip Subject: Data after a FIN Message-ID: <860615162744.2.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Sun, 15-Jun-86 16:27:00 EDT Article-I.D.: FIREBIRD.860615162744.2.DCP Posted: Sun Jun 15 16:27:00 1986 Date-Received: Wed, 18-Jun-86 03:12:28 EDT References: <860414094641.6.DCP@FIREBIRD.SCRC.Symbolics.COM> Sender: daemon@styx.UUCP Organization: The ARPA Internet Lines: 59 Approved: tcp-ip@sri-nic.arpa Date: Mon, 14 Apr 86 09:46 EST From: David C. Plummer We are noticing several hosts (e.g., UTAH-CS) that are sending a FIN, then sending data, and finally a second FIN. Technically, The spec says this should happen and the data should be discarded. What I want to know is - Who is doing this (I suspect 4.3BSD)? and - Why? and - Why doesn't anybody else know about it? I was under the impression this list was a clearing-house for ideas, but have absolutely no recollection of this being discussed. This is still the case and here is some analysis. In and Out refer to the packet direction from my local machine. My local machine is called FIREBIRD and is at address 192.10.41.161 and will be notated F below (to save space). UTAH-CS is at address 10.0.0.4 and will be notated U. The number after the dash is the port number; 79 is the NAME protocol. I've deleted the window-size field (they were always large enough for all data) and the time-recorded field (it all happened within 4 seconds). A,P,S and F stand for Ack, Push, Syn and Fin, respectively. Commentary included (commentary is below the segment it is commenting on). Out S F-1069->U-79 Seq=1915863851. Len=1 I ask for a connection. In A S U-79->F-1069 Seq=1982144000. Ack=1915863852. Len=1 Utah responds with a SYN and ACKs my SYN. Out A F-1069->U-79 Seq=1915863852. Ack=1982144001. Len=0 I ack Utah's SYN. Out AP F-1069->U-79 Seq=1915863852. Ack=1982144001. Len=2 I send a newline (which is what the name protocol wants). In A U-79->F-1069 Seq=1982144001. Ack=1915863854. Len=0 Utah ACKs my data. In A U-79->F-1069 Seq=1982144001. Ack=1915863854. Len=512 Utah sends me 512 bytes of data. In AP U-79->F-1069 Seq=1982144513. Ack=1915863854. Len=16 Utah sends me some more data. In A F U-79->F-1069 Seq=1982144529. Ack=1915863854. Len=1 Utah sends me a FIN. All of this is in order. Out A F-1069->U-79 Seq=1915863854. Ack=1982144530. Len=0 I acknowledge all of Utah's DATA and the FIN. In A F U-79->F-1069 Seq=1982144530. Ack=1915863854. Len=1 >> Utah sends me another FIN beyond the one it already sent me! Out A F F-1069->U-79 Seq=1915863854. Ack=1982144530. Len=1 After the user process gobbles the data, it closes the connection. This acknowledges Utah's FIN (again) and asserts my own FIN. In A U-79->F-1069 Seq=1982144001. Ack=1915863854. Len=512 Utah sends the first segment of data again(!) and ACKs my request, but not my FIN. [This may be a packet sequencing manifestation and can probably be ignored.] Out A F-1069->U-79 Seq=1915863855. Ack=1982144530. Len=0 I again ACK Utah's FIN. In A U-79->F-1069 Seq=1982144530. Ack=1915863855. Len=0 Utah finally ACKs my FIN and the connection is closed. Why is Utah sending a double FIN? Is anybody out there listening? I had no response from my query two months ago. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606170710.AA21126%40ACC-SB-UNIX.ARPA] <1986061623100900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rms@ACC-SB-UNIX.ARPA (Ron Stoughton) Newsgroups: mod.protocols.tcp-ip Subject: PSN 6.0 Battle Scars Message-ID: <8606170710.AA21126@ACC-SB-UNIX.ARPA> Date: Tue, 17-Jun-86 03:10:09 EDT Article-I.D.: ACC-SB-U.8606170710.AA21126 Posted: Tue Jun 17 03:10:09 1986 Date-Received: Thu, 19-Jun-86 07:42:50 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 114 Approved: tcp-ip@sri-nic.arpa There have been some inquiries lately regarding the inter-operability of X.25 with 1822 using PSN 6.0 in Standard mode. I believe a subsequent reply stated that PSN 6.0 supports such inter-operability. Recent testing we have done at customer sites has confirmed this, but some problems appear to exist in the PSN 6.0 software. A couple of these are described below in an effort to assist users attempting to connect to MILNET using Standard mode X.25. We would appreciate hearing from anyone experiencing similar problems since debugging of such can be very time consuming. Battle #1: This configuration consisted of our IBM MVS host in Columbia connected to the same IMP as our VAX running 4.2 BSD Unix. The VAX system was connected via an ACC IF-11/HDH interface running HDH (1822-J) packet mode at 19.2K bps. The IBM system was connected via an ACC IF-370/DDN interface running X.25 Standard at 57.6K bps. The problem occurred when attempting to log onto the IBM system from a VAX terminal using Telnet and manifested itself has a permanent hang condition during the logon sequence. The hang occurred when the IBM system sent a long message prompting for input. This message was sent across the X.25 interface as a 2-packet sequence (128-byte packet size) and was sent across the HDH interface as a 3-packet sequence (leader packet plus two data packets). However, the middle packet was 134 bytes in length which is a violation of the HDH protocol which specifies a middle packet length in the range of 2 to 126 bytes. This oversize packet was dutifully discarded by the HDH interface, thus causing a subsequent retransmission by TCP which repeated the error. Battle #2: This configuration consisted of an IBM VM host located at the Navy Yard (NARDAC) connected to a PSN 6.0 IMP via an ACC IF-370/DDN interface running X.25 Standard at 9.6K bps. It was discovered that FTPing the host table from the NIC took an extraordinarily long time (it actually appeared to be hung) and caused X.25 packet-level errors at our interface. However, transferring the same file from our IBM host in Columbia completed as expected and without error. In this case our IBM host in Columbia was connected via an ACC IF-370/1822 interface running distant host 1822 across a 9.6K bps ECU connection to the PSN 5.0 IMP at NIH. The NIC is connected to its local MILNET PSN 5.0 IMP via a BBN 1822 interface running in local or distant mode. Being a local IMP connection, the NIC interface will run at the asynchronous speed of the C/30's 1822 interface. We investigated this further with a Chameleon X.25 Data Analyzer and found the PSN 6.0 IMP was transmitting several IP datagrams concatenated together into a single X.25 packet sequence (i.e., the M-bit was set for several [how about 14?] successive X.25 packets). Each full-size (576-byte) IP datagram was also truncated to two 128-byte X.25 packets. In other words, the sequence of packets was: Packet Content 1 TCP/IP Header [Datagram n, Len=576], Data, M=1 2 Data, M=1 3 TCP/IP Header [Datagram n+1, Len=576], Data, M=1 4 Data, M=1 5 TCP/IP Header [Datagram n+2, Len=576], Data, M=1 6 Data, M=1 7 TCP/IP Header [Datagram n+3, Len=576], Data, M=1 8 Data, M=1 9 TCP/IP Header [Datagram n+4, Len=576], Data, M=1 10 Data, M=1 . . . . . . The proper sequence should have been: Packet Content 1 TCP/IP Header [Datagram n, Len=576], Data, M=1 2 Data, M=1 3 Data, M=1 4 Data, M=1 5 Data, M=0 6 TCP/IP Header [Datagram n+1, Len=576], Data, M=1 7 Data, M=1 8 Data, M=1 9 Data, M=1 10 Data, M=0 . . . . . . The above two problems are similar in that they both occur at the packet level and the data source is much faster than the data sink. However, since one occurs in HDH and the other in X.25, I don't expect they are related. Battle #3 We are still investigating this problem, but some preliminary info may be of interest to the community. We have multiple sites connected with identical IF-370/DDN interfaces to PSN 6.0 IMPs. All but one are running without problems except as noted above. The exception is 1ISG which is unable to run at all due to the IMP rejecting our call request packets. The indication from the IMP is that our precedence facility code is being administratively disallowed. Both ACC and BBN have compared the configuration parameters of the various IMPs and found them to be the same. In order to eliminate our hardware as the culprit, we canned some X.25 sequences on the Chameleon and fired them at the IMP to see what it would do. As expected, it accepted call requests as long as they didn't contain the precedence facility. One would conclude that there is an obvious difference in the configuration of the IMP port to which we are attached, but so far it has eluded BBN. Anyone with similar X.25 battle stories is encouraged to share them with the tcp/ip community so that we don't debug the same problem multiple times. Ron Stoughton RMS@ACC-SB-UNIX.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986061705574900> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Tue 17 Jun 86 13:08:31-PDT Date: 17 Jun 1986 12:57:49 PDT From: POSTEL@USC-ISIB.ARPA Subject: ISI moves to EDU domain To: tcp-ip@SRI-NIC.ARPA The Domain Name System has been developed to improve the maintenance and access of host name data. It is now ready for implementation, and policies have been adopted for converting all ARPA hosts to this system. These policies require that the general nature of an organization which supports a host be reflected in the host's name, i.e., Educational (EDU), Commercial (COM), or Military (MIL). ISI is classified as Educational and will thus be in the EDU domain. Note that the policies also require that the ARPA domain be phased out. The official ISI host names will be changed on Sunday, June 29th. The new name for USC-ISIB.ARPA will be B.ISI.EDU. The old official name, USC-ISIB.ARPA, will continue to be a nickname; however, old nicknames such as USC-ISIB and ISIB will be phased out over the next few months. Please begin notifying users who send you mail using these old nicknames that they should begin using the new official name to avoid mail delivery failures after the nicknames are invalid. In addition, it is important that all mailing list files be modified to use the new official names (i.e., user@B.ISI.EDU). The other primary ISI hosts below will also be adopting the new domain style names: Current Host Name New Official Name ================= ================= USC-ISI.ARPA A.ISI.EDU USC-ISIC.APRA C.ISI.EDU USC-ISID.ARPA D.ISI.EDU USC-ISIE.ARPA E.ISI.EDU USC-ISIF.ARPA F.ISI.EDU ISI-VAXA.ARPA VAXA.ISI.EDU ISI-VENERA.ARPA VENERA.ISI.EDU ADA-VAX.ARPA ADA-VAX.ISI.EDU If you have questions regarding this issue, please contact ACTION@ISI for assistance. Vicki Gordon ISI Host Administrator ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606180041.AA00277%40ucbvax.Berkeley.EDU] <1986061711574900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: POSTEL@USC-ISIB.ARPA Newsgroups: mod.protocols.tcp-ip Subject: ISI moves to EDU domain Message-ID: <8606180041.AA00277@ucbvax.Berkeley.EDU> Date: Tue, 17-Jun-86 15:57:49 EDT Article-I.D.: ucbvax.8606180041.AA00277 Posted: Tue Jun 17 15:57:49 1986 Date-Received: Thu, 19-Jun-86 07:46:42 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 42 Approved: tcp-ip@sri-nic.arpa The Domain Name System has been developed to improve the maintenance and access of host name data. It is now ready for implementation, and policies have been adopted for converting all ARPA hosts to this system. These policies require that the general nature of an organization which supports a host be reflected in the host's name, i.e., Educational (EDU), Commercial (COM), or Military (MIL). ISI is classified as Educational and will thus be in the EDU domain. Note that the policies also require that the ARPA domain be phased out. The official ISI host names will be changed on Sunday, June 29th. The new name for USC-ISIB.ARPA will be B.ISI.EDU. The old official name, USC-ISIB.ARPA, will continue to be a nickname; however, old nicknames such as USC-ISIB and ISIB will be phased out over the next few months. Please begin notifying users who send you mail using these old nicknames that they should begin using the new official name to avoid mail delivery failures after the nicknames are invalid. In addition, it is important that all mailing list files be modified to use the new official names (i.e., user@B.ISI.EDU). The other primary ISI hosts below will also be adopting the new domain style names: Current Host Name New Official Name ================= ================= USC-ISI.ARPA A.ISI.EDU USC-ISIC.APRA C.ISI.EDU USC-ISID.ARPA D.ISI.EDU USC-ISIE.ARPA E.ISI.EDU USC-ISIF.ARPA F.ISI.EDU ISI-VAXA.ARPA VAXA.ISI.EDU ISI-VENERA.ARPA VENERA.ISI.EDU ADA-VAX.ARPA ADA-VAX.ISI.EDU If you have questions regarding this issue, please contact ACTION@ISI for assistance. Vicki Gordon ISI Host Administrator ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606181738.AA11047%40pucc-j] <1986061809383800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: abe@ASC.PURDUE.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Information needed on available core gateway machines Message-ID: <8606181738.AA11047@pucc-j> Date: Wed, 18-Jun-86 13:38:38 EDT Article-I.D.: pucc-j.8606181738.AA11047 Posted: Wed Jun 18 13:38:38 1986 Date-Received: Fri, 20-Jun-86 00:46:22 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa I am interested in obtaining information on the available machines that can be used as core gateways. I am aware of the BBN Butterfly, but of not much more. Please reply by mail. Vic Abell, Purdue University Computing Center, abe@asc.purdue.edu ...!pur-ee!pucc-j!abe ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606182324.AA28057%40eros.DEC.COM] <1986061815240000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: johnsson@DECWRL.DEC.COM (Richard Johnsson) Newsgroups: mod.protocols.tcp-ip Subject: EGP trouble Message-ID: <8606182324.AA28057@eros.DEC.COM> Date: Wed, 18-Jun-86 19:24:00 EDT Article-I.D.: eros.8606182324.AA28057 Posted: Wed Jun 18 19:24:00 1986 Date-Received: Fri, 20-Jun-86 02:54:34 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa I have recently noticed (I can't say if it recently happened :-) that my EGP process is having disagreements with the EGP core gateways on MILNET. I seem to acquire a neighbor and load the routes from it. A few minutes later the EGP process reports bad checksums and after three minutes drops the neighbor and switches to the other one. Needless to say this is causing us some grief as the routes keeping coming and going every few minutes. I have several questions: 1. Is there something funny going with the EGP core on MILNET? 2. Are there EGP core gateways on MILNET other than AERONET-GW and BBN-MINET-A-GW? 3. Is there newer/better EGP code for BSD Unix systems than what I have? I'm running Paul Kirton's EGP User Process with documentation dated 23-Aug-84 which I fetched (I believe from ISI) in September 1984. Richard Johnsson ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606191130.AA04247%40nrl-css.ARPA] <1986061903304300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mullen@nrl-css.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: EGP trouble Message-ID: <8606191130.AA04247@nrl-css.ARPA> Date: Thu, 19-Jun-86 07:30:43 EDT Article-I.D.: nrl-css.8606191130.AA04247 Posted: Thu Jun 19 07:30:43 1986 Date-Received: Fri, 20-Jun-86 04:50:41 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa In reference to yesterday's message from johnsson@decwrl.DEC.COM, we recently started seeing the same thing here at NRL-CSS.ARPA. We're unable to get beyond MILNET most of the time. Could we perhaps have an acknowledgement that someone appropriate is looking into the problem? I've reported it to hostmaster@nic and milnetmgr@ddn1, but I'm not sure those are the right people to notify. Thanks. Preston Mullen Computer Science and Systems Branch (Code 7590) Naval Research Laboratory Washington DC 20375-5000 202 767-3507 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606191456.AA06240%40ucbvax.Berkeley.EDU] <1986061906133900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@BBNCCV.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: EGP trouble (gateway problems..) Message-ID: <8606191456.AA06240@ucbvax.Berkeley.EDU> Date: Thu, 19-Jun-86 10:13:39 EDT Article-I.D.: ucbvax.8606191456.AA06240 Posted: Thu Jun 19 10:13:39 1986 Date-Received: Fri, 20-Jun-86 04:51:33 EDT References: <8606191130.AA04247@nrl-css.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa Could we perhaps have an acknowledgement that someone appropriate is looking into the problem? I've reported it to hostmaster@nic and milnetmgr@ddn1, but I'm not sure those are the right people to notify. When there's a problem with the core gateway system, or you suspect gateway routing, you should call the NOC (Network Operations Center) at 800-492-4992 (or in Massachusetts, 617-497-2900). Be prepared to name names (or net addresses) of unreachable nets or hosts. The tcp-ip mailing list is a bit slow for reporting current operational problems. BBN gateway people are looking into the lack of routing info or EGP availablity. The first info is that both BBN-MINET-A-GW (26.1.0.40) and AERONET-GW (26.8.0.65) have been up continuously on MILNET since Monday 13:30 (minet) and Tuesday 18:17 (aero). The third EGP gateway at YUMA-GW (26.3.0.75) has been down since Wednesday 0900 while the site is changing power service. Mike Brescia 617-497-3662 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986061906133901> Received: from BBNCCV.ARPA by SRI-NIC.ARPA with TCP; Thu 19 Jun 86 07:19:51-PDT To: Preston Mullen cc: tcp-ip@sri-nic.ARPA, hoey@nrl-aic.ARPA, brescia@BBNCCV.ARPA cc: milnetmgr@ddn1.ARPA, hostmaster@sri-nic.ARPA Subject: Re: EGP trouble (gateway problems..) In-reply-to: Your message of 19 Jun 86 07:30:43 EDT (Thu). <8606191130.AA04247@nrl-css.ARPA> Date: 19 Jun 86 10:13:39 EDT (Thu) From: Mike Brescia Could we perhaps have an acknowledgement that someone appropriate is looking into the problem? I've reported it to hostmaster@nic and milnetmgr@ddn1, but I'm not sure those are the right people to notify. When there's a problem with the core gateway system, or you suspect gateway routing, you should call the NOC (Network Operations Center) at 800-492-4992 (or in Massachusetts, 617-497-2900). Be prepared to name names (or net addresses) of unreachable nets or hosts. The tcp-ip mailing list is a bit slow for reporting current operational problems. BBN gateway people are looking into the lack of routing info or EGP availablity. The first info is that both BBN-MINET-A-GW (26.1.0.40) and AERONET-GW (26.8.0.65) have been up continuously on MILNET since Monday 13:30 (minet) and Tuesday 18:17 (aero). The third EGP gateway at YUMA-GW (26.3.0.75) has been down since Wednesday 0900 while the site is changing power service. Mike Brescia 617-497-3662 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606191715.AA01238%40eros.DEC.COM] <1986061909150000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: johnsson@DECWRL.DEC.COM (Richard Johnsson) Newsgroups: mod.protocols.tcp-ip Subject: Re: EGP trouble Message-ID: <8606191715.AA01238@eros.DEC.COM> Date: Thu, 19-Jun-86 13:15:00 EDT Article-I.D.: eros.8606191715.AA01238 Posted: Thu Jun 19 13:15:00 1986 Date-Received: Fri, 20-Jun-86 20:01:00 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa On a suggestion from bruce@Think.COM I changed MAXPACKETSIZE from 576 to 1006 and things got a lot better. No more checksum complaints and I'm able to hang on to my neighbor once acquired. In looking at a trace of the routing activity, there seems to be a lot of bouncing around. Several networks I checked on get new metrics about every 4 minutes. Usually the gateway remains the same but the metric bounces between 4 and 5 or 5 and 6. Although my immediate problem is solved, it looks like things are still not completely healthy. Richard ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606191626.AA25379%40mitre-bedford.ARPA] <1986061909372200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bnsw@MITRE-BEDFORD.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: EGP trouble Message-ID: <8606191626.AA25379@mitre-bedford.ARPA> Date: Thu, 19-Jun-86 13:37:22 EDT Article-I.D.: mitre-be.8606191626.AA25379 Posted: Thu Jun 19 13:37:22 1986 Date-Received: Fri, 20-Jun-86 05:02:06 EDT References: <8606182324.AA28057@eros.DEC.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Bedford, MA Lines: 15 Approved: tcp-ip@sri-nic.arpa Due to the havoc EGP has been doing with routing info and the user confusion factor, I have turned off EGP. We are a Milnet site with a subnet. I also noticed that we received additional routing info for our subnet that identified bbn-milnet-gw,arpa-milnet-gw,sri-milnet-gw,sac-milnet-gw, and isi-milnet-gw as gateways to our subnet. This is useless info from our side and is not removed after the EGP bad checksums/cease of core gateway when the other routes are zapped. (just to provide more info for solving the problem...) Can a status report be sent out to this distro list when the problem has been fixed? I haven't seen any help. Thanks, Barbara Seeber-Wagner ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606191943.AA01211%40monet.Berkeley.EDU] <1986061911432400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: karels@MONET.BERKELEY.EDU (Mike Karels) Newsgroups: mod.protocols.tcp-ip Subject: Re: EGP trouble Message-ID: <8606191943.AA01211@monet.Berkeley.EDU> Date: Thu, 19-Jun-86 15:43:24 EDT Article-I.D.: monet.8606191943.AA01211 Posted: Thu Jun 19 15:43:24 1986 Date-Received: Fri, 20-Jun-86 20:14:46 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa It sounds as if the milnet has re-discovered a bug in Kirton's egp. The same thing happened on the arpanet some months ago; I think it was discussed on egp-people. The problem was that routing packets grew larger than the receive buffer, resulting in truncated packets that won't checksum. The simple "fix" is to increase the definition MAXPACKETSIZE to a "large" value; I used 2048, then added code to detect truncation. I have a handful of other bug fixes and tracing hooks for Kirton's egp, but some of it isn't very well tested. Also, it includes minor modifications for 4.3BSD, which now leaves the IP header on ICMP packets as it does for other raw IP protocols. I can make these changes available when it's cleaned up a bit. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860619155016.9.DCP%40FIREBIRD.SCRC.Symbolics.COM] <1986061911500000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.Symbolics.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: [Lepreau@UTAH-20.ARPA: Re: Data after a FIN] Message-ID: <860619155016.9.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Thu, 19-Jun-86 15:50:00 EDT Article-I.D.: FIREBIRD.860619155016.9.DCP Posted: Thu Jun 19 15:50:00 1986 Date-Received: Sat, 21-Jun-86 01:16:42 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa FYI, ============================== Date: Mon 16 Jun 86 18:50:25-MDT From: Jay Lepreau Subject: Re: Data after a FIN To: DCP@SCRC-QUABBIN.ARPA In-Reply-To: <860615162744.2.DCP@FIREBIRD.SCRC.Symbolics.COM> Message-ID: <12215395290.10.LEPREAU@UTAH-20.ARPA> Mike Karels says this has been fixed in the final 4.3 tape, which has been cut. I followed up on this before, I thought I told you about it. You can forward this on to the list if Mike doesn't respond himself in a little while. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606200634.AA18322%40ucbvax.Berkeley.EDU] <1986061912220300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: brescia@BBNCCV.ARPA (Mike Brescia) Newsgroups: mod.protocols.tcp-ip Subject: Re: EGP trouble Message-ID: <8606200634.AA18322@ucbvax.Berkeley.EDU> Date: Thu, 19-Jun-86 16:22:03 EDT Article-I.D.: ucbvax.8606200634.AA18322 Posted: Thu Jun 19 16:22:03 1986 Date-Received: Sat, 21-Jun-86 01:28:13 EDT References: <8606191626.AA25379@mitre-bedford.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 32 Approved: tcp-ip@sri-nic.arpa EGP Checksums? There was a problem with this in February, and a fix announced March 3, in the egp-people list (EGP-PEOPLE@bbnccv). ---- begin bug fix message ---- To: egp-people@BBNCCV.ARPA Cc: tmallory@BBNCCV.ARPA Subject: EGP Checksum errors Date: 03 Mar 86 17:29:23 EST (Mon) From: tmallory@BBNCCV.ARPA Most, if not all, users of the Kirton EGP code on the Arpanet have seen bad EGP checksum errors in recent weeks. The immediate source of the problem seems to be the following line(located with grep): defs.h:#define MAXPACKETSIZE 576 .... For now, redefining MAXPACKETSIZE to 1006 should take care of the immediate problem for Arpanet and Milnet sites ... ---- end of bug fix message If your site is running EGP and you are not now receiving the EGP-PEOPLE (egp-people@bbnccv) mailing list, I invite you to register your local distribution list (e.g. egp-people@your-site) or yourself for the list. Send a note to egp-people-request@bbnccv. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986061912220301> Received: from BBNCCV.ARPA by SRI-NIC.ARPA with TCP; Thu 19 Jun 86 13:27:05-PDT To: Barbara Seeber-Wagner cc: johnsson@decwrl.dec.com, tcp-ip@sri-nic.ARPA, brescia@BBNCCV.ARPA Subject: Re: EGP trouble In-reply-to: Your message of Thu, 19 Jun 86 12:26:00 -0500. <8606191626.AA25379@mitre-bedford.ARPA> Date: 19 Jun 86 16:22:03 EDT (Thu) From: Mike Brescia EGP Checksums? There was a problem with this in February, and a fix announced March 3, in the egp-people list (EGP-PEOPLE@bbnccv). ---- begin bug fix message ---- To: egp-people@BBNCCV.ARPA Cc: tmallory@BBNCCV.ARPA Subject: EGP Checksum errors Date: 03 Mar 86 17:29:23 EST (Mon) From: tmallory@BBNCCV.ARPA Most, if not all, users of the Kirton EGP code on the Arpanet have seen bad EGP checksum errors in recent weeks. The immediate source of the problem seems to be the following line(located with grep): defs.h:#define MAXPACKETSIZE 576 .... For now, redefining MAXPACKETSIZE to 1006 should take care of the immediate problem for Arpanet and Milnet sites ... ---- end of bug fix message If your site is running EGP and you are not now receiving the EGP-PEOPLE (egp-people@bbnccv) mailing list, I invite you to register your local distribution list (e.g. egp-people@your-site) or yourself for the list. Send a note to egp-people-request@bbnccv. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860620-022029-1697%40Xerox] <1986062001202400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Murray.pa@XEROX.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: IEEE and Ethernet Message-ID: <860620-022029-1697@Xerox> Date: Fri, 20-Jun-86 05:20:24 EDT Article-I.D.: Xerox.860620-022029-1697 Posted: Fri Jun 20 05:20:24 1986 Date-Received: Sat, 21-Jun-86 03:55:04 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Murray.pa@Xerox.COM Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa Not really IP or TCP, but probably interesting to many people on this list... IEEE 803.? recently agreed on a whole bunch of fine print for the specs for Ethernet repeaters, including fiber extensions. (There were major problems with the repeater handwaving in the blue book. Basically, it wouldn't work right if you were unlucky and you tried to push all the length limits.) If you need more info and can't get it through IEEE, I think I can find a local contact. As of January 1, 1986, Ethernet host numbers are now being assigned by the IEEE rather than Xerox. Any requests mailed to the Xerox address in the back of the blue book will get forwarded to the IEEE. (and delayed or...) The person to contact is Vince Condello at (212) 705-7092. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860622144033.6.DCP%40FIREBIRD.SCRC.Symbolics.COM] <1986062210400000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: IEEE and Ethernet Message-ID: <860622144033.6.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Sun, 22-Jun-86 14:40:00 EDT Article-I.D.: FIREBIRD.860622144033.6.DCP Posted: Sun Jun 22 14:40:00 1986 Date-Received: Mon, 23-Jun-86 06:30:14 EDT References: <860620-022029-1697@Xerox> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa Date: Fri, 20 Jun 86 02:20:24 PDT From: Murray.pa@Xerox.COM Not really IP or TCP, but probably interesting to many people on this list... IEEE 803.? recently agreed on a whole bunch of fine print for the specs for Ethernet repeaters, including fiber extensions. (There were major problems with the repeater handwaving in the blue book. Basically, it wouldn't work right if you were unlucky and you tried to push all the length limits.) If you need more info and can't get it through IEEE, I think I can find a local contact. As of January 1, 1986, Ethernet host numbers are now being assigned by the IEEE rather than Xerox. Any requests mailed to the Xerox address in the back of the blue book will get forwarded to the IEEE. (and delayed or...) The person to contact is Vince Condello at (212) 705-7092. I assume this applies to the protocol field as well? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12217139816.41.JNC%40XX.LCS.MIT.EDU] <1986062308332300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JNC@XX.LCS.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: IEEE and Ethernet Message-ID: <12217139816.41.JNC@XX.LCS.MIT.EDU> Date: Mon, 23-Jun-86 12:33:23 EDT Article-I.D.: XX.12217139816.41.JNC Posted: Mon Jun 23 12:33:23 1986 Date-Received: Thu, 26-Jun-86 23:32:03 EDT References: <860622144033.6.DCP@FIREBIRD.SCRC.Symbolics.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa The IEEE has flushed the protocol field (at least inside the Ethernet header) completely. They don't manage it, since they don't believe in it. The IEEE guy said to call Xerox. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860624153729.4.DCP%40FIREBIRD.SCRC.Symbolics.COM] <1986062411370000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.Symbolics.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Zero window probe opinion Message-ID: <860624153729.4.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Tue, 24-Jun-86 15:37:00 EDT Article-I.D.: FIREBIRD.860624153729.4.DCP Posted: Tue Jun 24 15:37:00 1986 Date-Received: Thu, 26-Jun-86 23:32:25 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa According to the spec, a segment that is not in the window is considered "unacceptable" and elicits an ACK (with zero segment text). This allows one to probe a zero window with the next sequence number out of the window (in case the window is open, but the segments conveying that informatin were lost). In theory, an implementation is allowed to completely ignore the window and it will work, but that is anti-social. My question: Is it considered "correct" to probe a zero window with only one byte, or is it still polite to probe it with some larger number that presumably fits in one segment (e.g., 1400+ on Ethernets)? [BTW, the first time I tried to send this message, I got this non-completion reply: Unable to deliver letter to the following recipient: tcp-ip@SRI-NIC.ARPA: SMTP error from SRI-NIC: 500 Syntax error or field too long: MAIL From: ] ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860624-141755-2789%40Xerox] <1986062412340500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Murray.pa@XEROX.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: IEEE and Ethernet Message-ID: <860624-141755-2789@Xerox> Date: Tue, 24-Jun-86 16:34:05 EDT Article-I.D.: Xerox.860624-141755-2789 Posted: Tue Jun 24 16:34:05 1986 Date-Received: Thu, 26-Jun-86 23:42:22 EDT References: <860620104633.4.DCP@FIREBIRD.SCRC.Symbolics.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa "I assume this applies to the protocol field as well?" The IEEE doesn't think anybody needs a protocol field. They use that word for the packet length. Thus I doubt very much if they are interested in assigning values. I don't know for sure though. Most of the existing protocol values were "grandfathered" in because they are invalid lengths. The official 802 position is that they don't care what consenting adults do with packets having invalid lengths. (There is probably a footnote along that line in the specs.) The only protocol field values that weren't big/lucky enough to get grandfathered this way are used for Pup. A pair of alternates have been assigned. The switchover is painful. Most places have ignored it. I think the Ethernet driver for the latest VMS now rejects old Pups. That doesn't make the switchover any easier, but it might make it happen sooner. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606242155.AA07228%40isi-braden.arpa] <1986062413555400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@USC-ISIB.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: tn3270 Message-ID: <8606242155.AA07228@isi-braden.arpa> Date: Tue, 24-Jun-86 17:55:54 EDT Article-I.D.: isi-brad.8606242155.AA07228 Posted: Tue Jun 24 17:55:54 1986 Date-Received: Thu, 26-Jun-86 23:39:36 EDT Sender: daemon@styx.UUCP Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa Greg: I just noticed the following in your README file for tn3270: It would be nice if the other TCP/IP on IBM (the UCLA code for MVS, and Spartacus code for VM) talked the same 3270-over-telnet protocol. The UCLA MVS code has talked the "same 3270-over-telnet protocol" for several years now. You obviously never asked. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606242318.AA19591%40orion.arpa] <1986062415180300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: medin@ORION.ARPA (Milo S. Medin, NASA ARC Code ED) Newsgroups: mod.protocols.tcp-ip Subject: Re: tn3270 Message-ID: <8606242318.AA19591@orion.arpa> Date: Tue, 24-Jun-86 19:18:03 EDT Article-I.D.: orion.8606242318.AA19591 Posted: Tue Jun 24 19:18:03 1986 Date-Received: Fri, 27-Jun-86 23:47:14 EDT References: <8606242155.AA07228@isi-braden.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa I use tn3270 to talk to our VM/CMS system using Spartacus KNET, and it works fine... Milo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606250040.AA11384%40sri-azteca.ARPA] <1986062416404500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: garcia%sri-azteca@sri-tsc (J. Joaquin Garcia-Luna) Newsgroups: mod.protocols.tcp-ip Subject: SIGCOMM '86 SYMPOSIUM Message-ID: <8606250040.AA11384@sri-azteca.ARPA> Date: Tue, 24-Jun-86 20:40:45 EDT Article-I.D.: sri-azte.8606250040.AA11384 Posted: Tue Jun 24 20:40:45 1986 Date-Received: Fri, 27-Jun-86 23:47:36 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 28 Approved: tcp-ip@sri-nic.arpa The following information may be of interest to you all. JJ ---------- ACM SIGCOMM '86 SYMPOSIUM. Stowe, Vermont; April 5, 6 & 7. The symposium features 45 papers chosen from over 120 submissions. Bob Kahn is the keynote speaker (Developing an Advanced Communications Infrastructure). Carl Sunshine (network interconnection and gateways) and Najah Naffah (distributed message systems) are the two tutorial speakers. The topics of the paper sessions include: local area networks, voice/data integration, protocol engineering, network algorithms, performance analysis, security and access control, and design and analysis of transport-level protocols including TCP. Of particular interest to the tcp-ip list may be the sessions "Modeling of Transport Protocols" (chair: Mike Ferguson) and "Protocols for Interprocess Communication" (chair: Bob Braden). One of the two winners of ACM SIGCOMM 86's student paper award contest is L. Zhang for her paper "Why TCP Timers Don't Work Well." For more information about symposium and tutorials, and preferred registration, contact Jose Garcia-Luna before July 20, 1986. Postal address: SRI International, 333 Ravenswood Ave., Menlo Park, CA 94025; Tel: (415) 859-5647 or (415)859-6366; Telex: 334486; ARPANET: garcia@sri-tsc. Else, contact Prof. Frank Vanecek, SIGCOMM '86, Norwich University, Dewey Hall, Northfield, Vermont 05663, USA; Tel: (802)485-5011. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606250043.AA11404%40sri-azteca.ARPA] <1986062416435800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: garcia%sri-azteca@sri-tsc (J. Joaquin Garcia-Luna) Newsgroups: mod.protocols.tcp-ip Subject: #2 SIGCOMM '86 SYMPOSIUM Message-ID: <8606250043.AA11404@sri-azteca.ARPA> Date: Tue, 24-Jun-86 20:43:58 EDT Article-I.D.: sri-azte.8606250043.AA11404 Posted: Tue Jun 24 20:43:58 1986 Date-Received: Sat, 28-Jun-86 00:10:43 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 32 Approved: tcp-ip@sri-nic.arpa I blew it in the date for SIGCOMM 86. It is August 5, 6 and 7 '86. JJ ---------- The following information may be of interest to you all. JJ ---------- ACM SIGCOMM '86 SYMPOSIUM. Stowe, Vermont; AUGUST 5, 6 & 7. The symposium features 45 papers chosen from over 120 submissions. Bob Kahn is the keynote speaker (Developing an Advanced Communications Infrastructure). Carl Sunshine (network interconnection and gateways) and Najah Naffah (distributed message systems) are the two tutorial speakers. The topics of the paper sessions include: local area networks, voice/data integration, protocol engineering, network algorithms, performance analysis, security and access control, and design and analysis of transport-level protocols including TCP. Of particular interest to the tcp-ip list may be the sessions "Modeling of Transport Protocols" (chair: Mike Ferguson) and "Protocols for Interprocess Communication" (chair: Bob Braden). One of the two winners of ACM SIGCOMM 86's student paper award contest is L. Zhang for her paper "Why TCP Timers Don't Work Well." For more information about symposium and tutorials, and preferred registration, contact Jose Garcia-Luna before July 20, 1986. Postal address: SRI International, 333 Ravenswood Ave., Menlo Park, CA 94025; Tel: (415) 859-5647 or (415)859-6366; Telex: 334486; ARPANET: garcia@sri-tsc. Else, contact Prof. Frank Vanecek, SIGCOMM '86, Norwich University, Dewey Hall, Northfield, Vermont 05663, USA; Tel: (802)485-5011. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860624225230.7.DCP%40FIREBIRD.SCRC.Symbolics.COM] <1986062418520000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) Newsgroups: mod.protocols.tcp-ip Subject: Re: IEEE and Ethernet Message-ID: <860624225230.7.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Tue, 24-Jun-86 22:52:00 EDT Article-I.D.: FIREBIRD.860624225230.7.DCP Posted: Tue Jun 24 22:52:00 1986 Date-Received: Sat, 28-Jun-86 00:11:46 EDT References: <860624-141755-2789@Xerox> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa Date: Tue, 24 Jun 86 13:34:05 PDT From: Murray.pa@Xerox.COM "I assume this applies to the protocol field as well?" The IEEE doesn't think anybody needs a protocol field. They use that word for the packet length. Thus I doubt very much if they are interested in assigning values. I don't know for sure though. Most of the existing protocol values were "grandfathered" in because they are invalid lengths. The official 802 position is that they don't care what consenting adults do with packets having invalid lengths. (There is probably a footnote along that line in the specs.) The only protocol field values that weren't big/lucky enough to get grandfathered this way are used for Pup. A pair of alternates have been assigned. The switchover is painful. Most places have ignored it. I think the Ethernet driver for the latest VMS now rejects old Pups. That doesn't make the switchover any easier, but it might make it happen sooner. OK, my ignorance is showing. Given that what used to be the protocol field is now the length, how does one determine what layer (protocol) the packet is really for? I assume there is still a 16 bit field SOMEPLACE. Who assigns those numbers? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606261719.AA06217%40ucbvax.Berkeley.EDU] <1986062509310000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: art@ACC.ARPA Newsgroups: mod.protocols.tcp-ip Subject: RE: IEEE 802.3 Message-ID: <8606261719.AA06217@ucbvax.Berkeley.EDU> Date: Wed, 25-Jun-86 13:31:00 EDT Article-I.D.: ucbvax.8606261719.AA06217 Posted: Wed Jun 25 13:31:00 1986 Date-Received: Sat, 28-Jun-86 00:16:00 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 35 Approved: tcp-ip@sri-nic.arpa > "I assume this applies to the protocol field as well?" > > The IEEE doesn't think anybody needs a protocol field. They use that > word for the packet length. Thus I doubt very much if they are > interested in assigning values. I don't know for sure though. > > ... > > OK, my ignorance is showing. Given that what used to be the protocol > field is now the length, how does one determine what layer (protocol) > the packet is really for? I assume there is still a 16 bit field > SOMEPLACE. Who assigns those numbers? IEEE 802 divides link level services into two sublayers, Media Access Control (MAC) and Logical Link Control (LLC). Different MAC layers are defined for various LAN types, 802.3 for CSMA/CD (ethernet), 802.4 Token Bus (used by MAP), and 802.5 Token Ring (the IBM ring). All MAC layers share a common LLC (802.2) which is supposed to provide a link level service which is independent of LAN type. The addressing of the next higher level user (protocol) has been moved into the LLC protocol header. The 802.3 MAC level header is nearly identical to the old ethernet header with the exception of the protocol field becoming a length field. LLC identifies its users through Link Service Access Points (LSAPs in ISOease). LSAPs are 8 bit quantities with two of those bits reserved for indicating single/multi recipient addressing and local/global SAP administration. This leaves room for 64 standard protocol identifiers. IEEE has assigned values for ISO IP and DARPA IP, but none for ARP. This has generated a lot of activity from the folks trying to convert TCP/IP/Ethernet systems to 802.3. There is a proposal to use a reserved LSAP value to identify an expanded LLC header with more addressing space. ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606252011.AA16304%40ll-xn.ARPA] <1986062512114800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: glenn@LL-XN.ARPA (Glenn Adams) Newsgroups: mod.protocols.tcp-ip Subject: FTP Problems Message-ID: <8606252011.AA16304@ll-xn.ARPA> Date: Wed, 25-Jun-86 16:11:48 EDT Article-I.D.: ll-xn.8606252011.AA16304 Posted: Wed Jun 25 16:11:48 1986 Date-Received: Sat, 28-Jun-86 00:16:37 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa In reviewing the current FTP specification (RFC959) I uncovered what seems to be a discrepancy. In the examples in Appendix II, on page 63, a response code of 200 is shown as the response to a CWD command. However, under the list of Command-Reply Sequences on page 50, CWD is shown to only accept a 250 response code. Since I interpret a CWD command as being excluded from the File System functional category, I assume that the response code of 200 is correct. Especially since CDUP as a special case of CWD does use 200. My motivation for reviewing the spec was a failure that occurred between a Symbolics LISPM Rel 6.1 FTP Client and a UNIX 4.3BSD FTP Server. The UNIX server gives a positive response code of 200 for the DELE command among others. The Symbolics FTP server accepts only a 250 positive response code. On the other hand, the UNIX FTP client ignores the response code completely. I suspect that the UNIX implementation is incorrect in not responding with the proper code; whereas, the Symbolics implementation is too conservative in the response codes accepted. --Glenn Adams ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606262242.AA11840%40ucbvax.Berkeley.EDU] <1986062606295600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: cassel@DEWEY.UDEL.EDU (Boots Cassel) Newsgroups: mod.protocols.tcp-ip Subject: ip model Message-ID: <8606262242.AA11840@ucbvax.Berkeley.EDU> Date: Thu, 26-Jun-86 10:29:56 EDT Article-I.D.: ucbvax.8606262242.AA11840 Posted: Thu Jun 26 10:29:56 1986 Date-Received: Sat, 28-Jun-86 00:18:49 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa Is anyone working on or aware of modelling efforts at the ip level? The IP packet queuing algorithm is of particular interest, but any modelling efforts at that level would be welcome. Thanks. Boots Cassel cassel@dewey.udel.EDU ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606261518.AA25760%40nprdc.arpa] <1986062607180000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bierma@NPRDC.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: tn3270 Message-ID: <8606261518.AA25760@nprdc.arpa> Date: Thu, 26-Jun-86 11:18:00 EDT Article-I.D.: nprdc.8606261518.AA25760 Posted: Thu Jun 26 11:18:00 1986 Date-Received: Sat, 28-Jun-86 00:24:59 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa The UNIX "tn3270" program works just fine connecting to the Spartacus Knet code for VM also. I use it all the time to connect to our 4341. --Larry ARPA: bierma@nprdc.arpa UUCP: {decvax,ucbvax,ihnp4}!sdcsvax!sdics!nprdc!bierma PSTN: (619) 225-2161 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606261538.AA1114602%40rclex.UUCP] <1986062607385700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: news@cdx39.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Test of path to mod.protocols.tcp-ip Message-ID: <8606261538.AA1114602@rclex.UUCP> Date: Thu, 26-Jun-86 11:38:57 EDT Article-I.D.: rclex.8606261538.AA1114602 Posted: Thu Jun 26 11:38:57 1986 Date-Received: Sat, 28-Jun-86 00:29:03 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 Approved: tcp-ip@sri-nic.arpa This is a test to see if we can reach the moderator for mod.protocols.tcp-ip via the path: rclex!harvard!tcp-ip@sri-nic.arpa Please let me know if this works. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606270252.AA15496%40ucbvax.Berkeley.EDU] <1986062609091800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: POSTEL@USC-ISIB.ARPA Newsgroups: mod.protocols.tcp-ip Subject: re: IEEE and Ethernet Message-ID: <8606270252.AA15496@ucbvax.Berkeley.EDU> Date: Thu, 26-Jun-86 13:09:18 EDT Article-I.D.: ucbvax.8606270252.AA15496 Posted: Thu Jun 26 13:09:18 1986 Date-Received: Sat, 28-Jun-86 00:29:27 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa David: Opening another can of worms ... In IEEE 802 the thing most similar to the Ethernet type is called a "service access point" or SAP, but it is only 8 bits and two of those are wasted on some other general coding, so there are only 64 SAPs to assign. So after assigning one to identify ISO-IP and one to identify DOD-IP, the IEEE 802 committee decided that there weren't enough and refused to assign a SAP to identify ARP. There is some committee work in progress to come up with an extended SAP field. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606270407.AA16353%40ucbvax.Berkeley.EDU] <1986062609294000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: jas@BRUBECK.PROTEON.COM Newsgroups: mod.protocols.tcp-ip Subject: Re: Re: IEEE and Ethernet Message-ID: <8606270407.AA16353@ucbvax.Berkeley.EDU> Date: Thu, 26-Jun-86 13:29:40 EDT Article-I.D.: ucbvax.8606270407.AA16353 Posted: Thu Jun 26 13:29:40 1986 Date-Received: Sat, 28-Jun-86 00:31:28 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: jas@proteon.com Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa The protocol numbers are in the 802.2 data link control header, which is standard for 802.3, 802.4, and 802.5. They are one byte, and are incredibly stricly regulated. Basically, they're only available to established international standards. There is a (they're called SAPs) for TCP/IP, but that was considered an EXCEPTION to the rule, as TCP/IP is not promulgated by an international standards body. The only allocated SAPs are: ISO IP and TCP/IP. Half of them are "unadministered", IBM has de-facto taken a group for SNA. You'll notice that ARP is not listed. A group of us are trying to work on this issue. (I can provide more gruesome details of the list, if desired.) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860626161800.4.DCP%40FIREBIRD.SCRC.Symbolics.COM] <1986062612180000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.Symbolics.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Re: IEEE and Ethernet Message-ID: <860626161800.4.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Thu, 26-Jun-86 16:18:00 EDT Article-I.D.: FIREBIRD.860626161800.4.DCP Posted: Thu Jun 26 16:18:00 1986 Date-Received: Sat, 28-Jun-86 08:50:12 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 42 Approved: tcp-ip@sri-nic.arpa Date: Thu, 26 Jun 86 13:29:40 EDT From: jas@brubeck.proteon.com The protocol numbers are in the 802.2 data link control header, which is standard for 802.3, 802.4, and 802.5. They are one byte, and are incredibly stricly regulated. Basically, they're only available to established international standards. There is a (they're called SAPs) for TCP/IP, but that was considered an EXCEPTION to the rule, as TCP/IP is not promulgated by an international standards body. The only allocated SAPs are: ISO IP and TCP/IP. Half of them are "unadministered", IBM has de-facto taken a group for SNA. You'll notice that ARP is not listed. A group of us are trying to work on this issue. (I can provide more gruesome details of the list, if desired.) I seem to remember seeing some mention of this fly by in the past, but took little notice. Oh well, if they want to be snob-headed and try to surpress vendor protocols (what about people who want to run PUP, CHAOS, XNS, DECnet) as well as supress research into protocols (i.e., how to avoid collision of an "unadministered" number between people developing new protocols that would take 4 years to become ISO anyway), I guess it's time to hope the aliens are coming and will put some sense into them. Sorry for the long, run-on sentence, flame. This might be a reasonable thing for tightly controlled comercial products, but comercial products don't pop up out of thin air, they need time for experimentation and development. Aren't they also snobbish enough not to need ARP? Don't you just "send it" and it "magically" gets there? I just realized what's ticking me off. This whole nonsense is a parallel with puritanical religions. It does not have any room for person freedom (e.g., elbow room for new protocols) and it doesn't have any concept of social responsibility (e.g., maybe isn't such a good idea, but AT THIS TIME IN THIS SOCIETY it is a necessary evil). Time to nail a grievance to somebody's door? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606252233.AA04228%40mitre-bedford.ARPA] <1986062613175800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: bjp@MITRE-BEDFORD.ARPA Newsgroups: mod.protocols.tcp-ip Subject: New Version of ULANA Specifications Message-ID: <8606252233.AA04228@mitre-bedford.ARPA> Date: Thu, 26-Jun-86 17:17:58 EDT Article-I.D.: mitre-be.8606252233.AA04228 Posted: Thu Jun 26 17:17:58 1986 Date-Received: Sat, 28-Jun-86 00:17:05 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Bedford, MA Lines: 17 Approved: tcp-ip@sri-nic.arpa A new version of the ULANA Specifications is available on the host, ulana. Directions on how to get here: ftp to mitre-b-ulana.arpa user: guest password: anonymous pathname: /usr/newusr/guest/ulana.specs internet address: 192.12.120.30 Please send all correspondence to bjp@mitre-bedford.arpa, as that is where I receive all my mail. All comments should be sent to this address, as well. Sincerely, bj Pease ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MS.leong.0.leong.194.4%40andrew.cmu.edu] <1986062613311800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: leong@ANDREW.CMU.EDU (John Leong) Newsgroups: mod.protocols.tcp-ip Subject: ARP on IBM token ring Message-ID: Date: Thu, 26-Jun-86 17:31:18 EDT Article-I.D.: andrew.MS.leong.0.leong.194.4 Posted: Thu Jun 26 17:31:18 1986 Date-Received: Sat, 28-Jun-86 00:30:02 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 50 Approved: tcp-ip@sri-nic.arpa For running IP on the IBM token ring, one has to handle ARP quite carefully (besides boring thing like SAP number as applicable to all LAN's using the 802.2 layer). The IBM token ring is sort of defined in the official 802.5 spec. What is missing in that definition is the bridge. Unlike Ethernet, inter-ring bridge is very much part of the IBM token ring since a basic ring will only support 260 stations due to potential jitter problem. (Bridge differs from a repeater in that it will store and forward if necessary). While IBM has contributed the Bridge design to IEEE, it was not included in the final spec. The IBM ring bridge works very different from the DEC LANbridge which is totally transparant to station software. The IBM bridge use source routing. In a simplified form, when a station does any broadcast, the bridge will forward the broadcast packet. it will also tag its ID in the Route Information Field of the packet. The Route Information Field, RIF, is considered as part of the MAC layer and below the LLC layer. When the broadcast packet gets to the other end, the receiving station will know the path. (The same thing applies to a special MAC frame called "resolve"). In the case of ARP, the recieving station must store the RIF in its ARP table since subsequent (non-broadcast) communication will have to be done with source routing : i.e. including the RIF field in the MAC header. The ARP reply must also incude the RIF as part of the hardware address so the ARP sender can source route its packet. This has at least two implications : (a) The hardware address of the ARP cache has to be a variable length (subject to a maximum : there is a maximum length for the RIF field). (b) There needs to be closer interfacing between the driver and the ARP layer since the driver must pass up the whole MAC header to the ARP handler so that the RIF field can be extracted. Personally, I think DEC's approach makes life much more easier. However, I think future revision of ARP specification for the 802 LAN's should take the above into consideration. John Leong ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606270047.AA17950%40ucbopal.Berkeley.Edu] <1986062616475600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: minshall%ucbopal@UCBVAX.BERKELEY.EDU (Greg Minshall) Newsgroups: mod.protocols.tcp-ip Subject: Re: tn3270 Message-ID: <8606270047.AA17950@ucbopal.Berkeley.Edu> Date: Thu, 26-Jun-86 20:47:56 EDT Article-I.D.: ucbopal.8606270047.AA17950 Posted: Thu Jun 26 20:47:56 1986 Date-Received: Sat, 28-Jun-86 00:33:50 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa Bob, Guilty as charged. I never asked if you did. My inherent view of the world (especially where anything blue is concerned) is cynical. Thanks for pointing out my error. By the way, I am also informed (though I have never verified it) that Spartacus also supports this mode of connecting. So, tn3270 can talk to IBM hosts running Spartacus, Wiscnet (whatever IBM calls it), or the UCLA code (including the ACC front end, I believe). Someday I'll change the README file. Greg ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860627135447.026144%40MIT-MULTICS.ARPA] <1986062705540000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Vinograd@MIT-MULTICS.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: tn3270 Message-ID: <860627135447.026144@MIT-MULTICS.ARPA> Date: Fri, 27-Jun-86 09:54:00 EDT Article-I.D.: MIT-MULT.860627135447.026144 Posted: Fri Jun 27 09:54:00 1986 Date-Received: Sat, 28-Jun-86 08:03:58 EDT Sender: daemon@styx.UUCP Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Might also note that KNET clients negociate with KNET servers ala tn3270, so IBM to IBM is in full screen mode. This is true both for the VM product, as well as the MVS product. And the negociation is based on the users' terminal so all models are supported, not just MOD2. Dave Vinograd ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606272158.AA12405%40trantor.UMD.EDU] <1986062713582800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: louie@TRANTOR.UMD.EDU (Louis A. Mamakos) Newsgroups: mod.protocols.tcp-ip Subject: Re: Re: IEEE and Ethernet Message-ID: <8606272158.AA12405@trantor.UMD.EDU> Date: Fri, 27-Jun-86 17:58:28 EDT Article-I.D.: trantor.8606272158.AA12405 Posted: Fri Jun 27 17:58:28 1986 Date-Received: Sat, 28-Jun-86 09:50:00 EDT Sender: daemon@styx.UUCP Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa It is because of things like this that standardization bodies have bad reputations. You can definitly smell a standard written by committee, with each member's own hidden agenda slipped in somewhere. This will delay acceptance and conversion from the DEC-Intel-XEROX Ethernet standard quite a while, at least around here. If it works, why break it? Standards are great; everyone should have one of their own. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860627194614.5.DCP%40FIREBIRD.SCRC.Symbolics.COM] <1986062715460000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: re: IEEE and Ethernet Message-ID: <860627194614.5.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Fri, 27-Jun-86 19:46:00 EDT Article-I.D.: FIREBIRD.860627194614.5.DCP Posted: Fri Jun 27 19:46:00 1986 Date-Received: Sat, 28-Jun-86 10:53:48 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 44 Approved: tcp-ip@sri-nic.arpa Date: 26 Jun 1986 10:09:18 PDT From: POSTEL@USC-ISIB.ARPA David: Opening another can of worms ... In IEEE 802 the thing most similar to the Ethernet type is called a "service access point" or SAP, but it is only 8 bits and two of those are wasted on some other general coding, so there are only 64 SAPs to assign. So after assigning one to identify ISO-IP and one to identify DOD-IP, the IEEE 802 committee decided that there weren't enough and refused to assign a SAP to identify ARP. There is some committee work in progress to come up with an extended SAP field. --jon. ------- [I'm probably sounding like a big flamer...] It really amazes me that people are trying to squeeze 300 options into 20 bits. This isn't the 1960s anymore. Just a few weeks ago a megabit ram chip costs $35. That's the equivalent of TWO, count'em, TWO PDP-11 (non-memory mapped) address spaces (2^16 bytes each). I recall hearing rumors about various namespace/domain proposals (the X, Y and Z proposals?) that tried to do similar bit cramming. IT ISN'T WORTH IT, folks. Maybe somebody should seriously suggest that IEEE 802 be scrapped and something more rational and less wasn't-invented-here be made to put in its place. Would Henry Nussbacher, if he is still out there, please resend the article he sent on 31 March 1985. It is a great story about the Mericos and the Eups on the planet Urth about trains with rubber-coatetd wheels. I don't remember what the analogy was then (probably the TP4 debate), but it is very fitting to the current situation. PS, I am still having mail troubles. These might be problems on our end. If so, tell me. If not, fix your end. Unable to deliver letter to the following recipients: POSTEL@USC-ISIB.ARPA: SMTP error from USC-ISIB: 501 Error in path -DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM TCP-IP@SRI-NIC.ARPA: Unknown response from host SRI-NIC: (expecting 220). ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12218271857.14.MRC%40SIMTEL20.ARPA] <1986062716115200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MRC@SIMTEL20.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: failed mail from DCP Message-ID: <12218271857.14.MRC@SIMTEL20.ARPA> Date: Fri, 27-Jun-86 20:11:52 EDT Article-I.D.: SIMTEL20.12218271857.14.MRC Posted: Fri Jun 27 20:11:52 1986 Date-Received: Sat, 28-Jun-86 10:56:02 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa The problem is in the SMTP sender at the Symbolics end. There is a bogus space after "MAIL From:" before the "<" that begins the return path. RFC 821 is quite specific about where spaces are expected and where they are not expected. You cannot say "MAIL FROM: ", you must say "MAIL FROM:". TOPS-20 isn't the only SMTP server that is fussy about this. Even some Unix-based servers insist upon compliance to the spec here. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860627201823.7.DCP%40FIREBIRD.SCRC.Symbolics.COM] <1986062716180000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Re: IEEE and Ethernet Message-ID: <860627201823.7.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Fri, 27-Jun-86 20:18:00 EDT Article-I.D.: FIREBIRD.860627201823.7.DCP Posted: Fri Jun 27 20:18:00 1986 Date-Received: Sat, 28-Jun-86 10:54:07 EDT References: <8606272158.AA12405@trantor.UMD.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa Date: Fri, 27 Jun 86 17:58:28 EDT From: Louis A. Mamakos It is because of things like this that standardization bodies have bad reputations. You can definitly smell a standard written by committee, with each member's own hidden agenda slipped in somewhere. A somewhat constructive question: Is it written down what the Charter and Goals of the 802 standards committee is? Is "to allow flexibility for experimentation" one of the goals? If not, then there are several organizations that will not be able to use 802 because they need the ability to experiment (and get work done, since non-ISO things are (by their definition) experimental). If so, I think they need to be informed they are not addressing this goal. This will delay acceptance and conversion from the DEC-Intel-XEROX Ethernet standard quite a while, at least around here. If it works, why break it? Standards are great; everyone should have one of their own. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860627202416.8.DCP%40FIREBIRD.SCRC.Symbolics.COM] <1986062716240000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.Symbolics.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Re: IEEE and Ethernet Message-ID: <860627202416.8.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Fri, 27-Jun-86 20:24:00 EDT Article-I.D.: FIREBIRD.860627202416.8.DCP Posted: Fri Jun 27 20:24:00 1986 Date-Received: Sat, 28-Jun-86 10:54:25 EDT References: <8606272158.AA12405@trantor.UMD.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 37 Approved: tcp-ip@sri-nic.arpa Date: Fri, 27 Jun 86 17:58:28 EDT From: Louis A. Mamakos It is because of things like this that standardization bodies have bad reputations. You can definitly smell a standard written by committee, with each member's own hidden agenda slipped in somewhere. A somewhat constructive question: Is it written down what the Charter and Goals of the 802 standards committee is? Is "to allow flexibility for experimentation" one of the goals? If not, then there are several organizations that will not be able to use 802 because they need the ability to experiment (and get work done, since non-ISO things are (by their definition) experimental). If so, I think they need to be informed they are not addressing this goal. BTW, the reason I wrote ARP the way I did is because I KNEW there was more than one protocol in the world, and that there would be more. (It was a bit easy, because I was trying to solve the same problem for two different protocols (CHAOS and IP).) I also knew the protocols had different length addresses, and thus the protocol-address-length field. I also knew that Ethernet was the only hardware medium. Thus the hardware-type field. I knew that addresses on different hardwares had different lengths, thus the hardware-address-length field. I knew that this would solve the GENERAL problem stated in the first three paragraphs (Introduction, The Problem, and Motivation). I know the real world is more diverse and more interesting than a one track (collective) mind. This will delay acceptance and conversion from the DEC-Intel-XEROX Ethernet standard quite a while, at least around here. If it works, why break it? Standards are great; everyone should have one of their own. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12218280995.20.SUE%40SRI-NIC.ARPA] <1986062717020400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HOSTMASTER@SRI-NIC.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: [HOSTMASTER@SRI-NIC.ARPA: Ohosts.txt file] Message-ID: <12218280995.20.SUE@SRI-NIC.ARPA> Date: Fri, 27-Jun-86 21:02:04 EDT Article-I.D.: SRI-NIC.12218280995.20.SUE Posted: Fri Jun 27 21:02:04 1986 Date-Received: Sat, 28-Jun-86 10:55:02 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: HOSTMASTER@SRI-NIC.ARPA Organization: The ARPA Internet Lines: 41 Approved: tcp-ip@sri-nic.arpa This message is forwarded as a reminder to all. --------------- Mail-From: SUE created at 18-Jun-86 16:44:39 Date: Wed 18 Jun 86 16:44:39-PDT From: HOSTMASTER@SRI-NIC.ARPA Subject: Ohosts.txt file Sender: SUE@SRI-NIC.ARPA To: Host-table-distribution: ; cc: HOSTMASTER@SRI-NIC.ARPA Reply-To: HOSTMASTER@SRI-NIC.ARPA Message-ID: <12215907606.34.SUE@SRI-NIC.ARPA> Dear network host table user: As of 1 July 1986, the DDN Network Information Center will no longer provide the OLD-STYLE host table, NETINFO:OHOSTS.TXT, and its accompanying binary file, NETINFO:OHOSTS3.BIN. These are the files that contain old non-domain style host names. According to DDN Management Bulletin 22, dated 16 March 1984, all hosts on ARPANET and MILNET were to have acquired new domain-style names by 21 March 1984 by adding ".ARPA" to the end of their names. To aid in the transition, the NIC has been providing both old and new style tables for over two years. After having surveryed all network sites several times, we have determined that very few hosts will be affected by the removal of these old-style tables. PLEASE NOTE: The NIC will continue to provide the official DoD host table NETINFO:HOSTS.TXT, and its accompanying binary file, NETINFO:HOSTS3.BIN. The official host table will be maintained indefinitely until a full transition to the domain system by all DDN subscribers is completed. Please address any questions or comments to HOSTMASTER@SRI-NIC.ARPA. Sue Romano DDN Network Information Center ------- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606281229.AA25219%40seismo.CSS.GOV] <1986062804294600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mo@SEISMO.CSS.GOV (Mike O'Dell) Newsgroups: mod.protocols.tcp-ip Subject: IEEE-ISO Brain Death Message-ID: <8606281229.AA25219@seismo.CSS.GOV> Date: Sat, 28-Jun-86 08:29:46 EDT Article-I.D.: seismo.8606281229.AA25219 Posted: Sat Jun 28 08:29:46 1986 Date-Received: Sat, 28-Jun-86 22:58:36 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 31 Approved: tcp-ip@sri-nic.arpa It is clear the dreaded ISOOSI virus rotted the brain tissue of the IEEE committee, but why not solve the problem simply... (1) ARP is basically part of the mechanism for encapsulating IP datagrams on a local network. (2) There is a LSAP (or whatever) assigned for the DOD-IP suite. So..... Just change the "official" IP encapsulation to start with a 16-bit TYPE field, followed by whatever is defined by that field. With that, you can get ARP, you can get IP, you can get experimental protocols, you can get on with your life in spite of the crufty IEEE spec. Problems?? It breaks things. Well, so does their change. And it is early in the upheaval cycle. The other alternative is to get an LSAP defined for an EXTENSIBLE structure, with a field, and an Official Assigner. That has far more geopolitical problems than getting IP implementers to use the "sanctioned" IP encapsulation, but is desirable for more global reasons. Anyway, this approach would solve our problem, and move its administration back into a universe with lower entropy and more reality. -Mike O'Dell (I guess this is really a "secret" OLD ETHERNET type disguised as DOD-IP. So be it. Someone has to be clever around here. It sure ain't the people designing standards.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606281614.AA09344%40ucbvax.Berkeley.EDU] <1986062807561000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: MILLS@USC-ISID.ARPA Newsgroups: mod.protocols.tcp-ip Subject: re: IEEE and Ethernet Message-ID: <8606281614.AA09344@ucbvax.Berkeley.EDU> Date: Sat, 28-Jun-86 11:56:10 EDT Article-I.D.: ucbvax.8606281614.AA09344 Posted: Sat Jun 28 11:56:10 1986 Date-Received: Sun, 29-Jun-86 04:13:02 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa In response to the message sent Fri, 27 Jun 86 19:46 EDT from DCP@QUABBIN.SCRC.Symbolics.COM David, Your recollection may be blamed on the Professor Finnegan Papers. Danny Cohen of ISI is curator of that museum. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606281750.AA09954%40ucbvax.Berkeley.EDU] <1986062809321500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: LYNCH@USC-ISIB.ARPA (Dan Lynch) Newsgroups: mod.protocols.tcp-ip Subject: Re: IEEE-ISO Brain Death Message-ID: <8606281750.AA09954@ucbvax.Berkeley.EDU> Date: Sat, 28-Jun-86 13:32:15 EDT Article-I.D.: ucbvax.8606281750.AA09954 Posted: Sat Jun 28 13:32:15 1986 Date-Received: Sun, 29-Jun-86 04:11:40 EDT References: <8606281229.AA25219@seismo.CSS.GOV> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa Mike (and others), This nasty little issue of living in a world not defined by us is one that can be meaningfully addressed at the TCP/IP Vendors Workshop at the end of August. At one time we will have in one room over 100 different TCP/IP implementation teams. WE can discuss not just the technical issues of the best way to cope with our bretheren in the ISO world, but how to make changes that are not disastrously disruptive to the customers in the field. (The most recent problem has been with subnetting and how it gets incorporated smoothly in the field. With over 100 different vendors it is impossible to coordinate release dates for protocol upgrades.) Meanwhile, perhaps some readers of this list have some experience running ISO IP as well as DoD IP on the same Ethernet and can reveal how they have dealt with it thus far. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12218560136.22.HEDRICK%40RED.RUTGERS.EDU] <1986062818352600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: Re: Re: IEEE and Ethernet Message-ID: <12218560136.22.HEDRICK@RED.RUTGERS.EDU> Date: Sat, 28-Jun-86 22:35:26 EDT Article-I.D.: RED.12218560136.22.HEDRICK Posted: Sat Jun 28 22:35:26 1986 Date-Received: Sun, 29-Jun-86 04:15:36 EDT References: <8606272158.AA12405@trantor.UMD.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa Do anyone know if there are plans to do a real 803.x implementation of IP, i.e. one that uses the type field as a length? One would suppose that the first vendor to do this would lose big, since no other implementation would talk to it. I would think a more natural approach would be for IP, PUP, etc., to continue using the type field as a type. Then if we see a packet with a value that is in the range of legal 803 lengths, we treat it as if it specified a type of ISO. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606290249.AA07349%40seismo.CSS.GOV] <1986062818491300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: rick@SEISMO.CSS.GOV (Rick Adams) Newsgroups: mod.protocols.tcp-ip Subject: Re: [HOSTMASTER@SRI-NIC.ARPA: Ohosts.txt file] Message-ID: <8606290249.AA07349@seismo.CSS.GOV> Date: Sat, 28-Jun-86 22:49:13 EDT Article-I.D.: seismo.8606290249.AA07349 Posted: Sat Jun 28 22:49:13 1986 Date-Received: Sun, 29-Jun-86 04:16:09 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa I trust you are also going to remove the non-domained aliases from hosts.txt also. I removed the alias "seismo" about a month ago. It was fascinating seeing how many things broke on other sites. The non-domained aliases should clearly be taken out of hosts.txt. (Otherwise pretending we are running with domains is a joke.) ---rick ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12218768556.10.MRC%40SIMTEL20.ARPA] <1986062913401900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MRC@SIMTEL20.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: HOSTS.TXT Message-ID: <12218768556.10.MRC@SIMTEL20.ARPA> Date: Sun, 29-Jun-86 17:40:19 EDT Article-I.D.: SIMTEL20.12218768556.10.MRC Posted: Sun Jun 29 17:40:19 1986 Date-Received: Sun, 29-Jun-86 23:51:31 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Here's another vote to remove the non-domained aliases from HOSTS.TXT. I'd like to see each host have a maximum of two names; the current domain name form (which should appear on all mail) and for a while the old ".ARPA" form. There is no excuse for any host which doesn't play the mail game to have more than one name (let's abolish TAC nicknames!). I would also like to propose that "NIC" be made a new top-level entity, and that the current SRI-NIC.ARPA machine be renamed simply "NIC" instead of something like "NIC.SRI.COM". The NIC is at SRI because SRI has the contract to run it, but in the (probably unlikely) event that SRI loses the contract there will still need to be a NIC. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606292329.AA07359%40titan.arc.nasa.gov] <1986062915290200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jordan@TITAN.ARC.NASA.GOV.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: HOSTS.TXT Message-ID: <8606292329.AA07359@titan.arc.nasa.gov> Date: Sun, 29-Jun-86 19:29:02 EDT Article-I.D.: titan.8606292329.AA07359 Posted: Sun Jun 29 19:29:02 1986 Date-Received: Sun, 29-Jun-86 23:52:14 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 34 Approved: tcp-ip@sri-nic.arpa I agree with Mark and Rick -- the non-domained aliases are just a sad excuse for not doing the right thing. I'm not sure, however about the restriction to two names -- some hosts have extra names for their plain domain name (ucbvax.Berkeley.EDU -> Berkeley.EDU, etc.) ... As for SRI-NIC.ARPA -> NIC, maybe it should be NIC.ORG, since the NIC (the organisation, not the machine) may in the future have more than one machine (maybe PCs or whatever) under their control. I agree, however, that it should not be in SRI's namespace. A question though ... my reading of RFC921 doesn't make it at all clear about the MILNET's obligation in all of this. I understand that DDN-PMO has yet to establish a schedule for the *implementation* part of the Domain system, but what about the naming part of it? It seems to say that the MILNET is on the same schedule for changing to "domained names" (which could, by definition, include .ARPA) ... If you change to .ARPA, you can certainly change to one of the other top-level domains, and we can be through with .ARPA once and for all. I was under the impression that the main problem was mailers, etc. that didn't understand "addresses with dots" ... certainly .ARPA has a dot. Is there in fact a requirement for the MILNET sites to join one of the non-dot-arpa top-level domains? I thought I remembered reading somewhere that part of the requirements for getting a domain is to provide nameservice for it (whether or not *you* use the server for address resolution I think is the crux of the "We don't care; we don't have to -- We're MILNET" argument). Why are new sites getting non-domained addresses? Also, to echo Mark, what about these TACs? /jordan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BSRI-NIC.ARPA%5D30-Jun-86.04:59:52.STJOHNS] <1986063003590000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: STJOHNS@SRI-NIC.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: HOSTS.TXT Message-ID: <[SRI-NIC.ARPA]30-Jun-86.04:59:52.STJOHNS> Date: Mon, 30-Jun-86 07:59:00 EDT Article-I.D.: <[SRI-NIC.ARPA]30-Jun-86.04:59:52.STJOHNS> Posted: Mon Jun 30 07:59:00 1986 Date-Received: Mon, 30-Jun-86 18:06:41 EDT References: <8606292329.AA07359@titan.arc.nasa.gov> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa We on the MILNET side of the house have been waiting patiently for those on the research side of the house to work out all the bugs in the domain system. And there are BUGS... err... "service deficiencies". You will be pleased to know that this subject is the major topic for the next meeting of the Internet Engineering Task Force. This should result in fallout which should shove the MILNET towards the domain system. Mike StJohns ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860630094220.1.JOSEPH%40HARLEM.SCRC.Symbolics.COM] <1986063005420000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: joseph@SAPSUCKER.SCRC.SYMBOLICS.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: failed mail from DCP Message-ID: <860630094220.1.JOSEPH@HARLEM.SCRC.Symbolics.COM> Date: Mon, 30-Jun-86 09:42:00 EDT Article-I.D.: HARLEM.860630094220.1.JOSEPH Posted: Mon Jun 30 09:42:00 1986 Date-Received: Mon, 30-Jun-86 18:07:50 EDT References: <12218271857.14.MRC@SIMTEL20.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa Date: Fri 27 Jun 86 18:11:52-MDT From: Mark Crispin The problem is in the SMTP sender at the Symbolics end. There is a bogus space after "MAIL From:" before the "<" that begins the return path. RFC 821 is quite specific about where spaces are expected and where they are not expected. You cannot say "MAIL FROM: ", you must say "MAIL FROM:". Quite correct. I fixed this last Monday or so. If you're still seeing this bogus space, please let me know the originating host at the "Symbolics end" so that I can find out why someone's running outdated software on it. TOPS-20 isn't the only SMTP server that is fussy about this. Even some Unix-based servers insist upon compliance to the spec here. Someone at a 4.2bsd site told me this "enforcement" took the form of many, many sendmail processes going into hard loops, pushing the load average up around 13 and chewing up more than 90% of the machine. The loopy processes have to be shot. He wasn't happy about it. -- joseph ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860630095315.5.DCP%40FIREBIRD.SCRC.Symbolics.COM] <1986063005530000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: failed mail from DCP Message-ID: <860630095315.5.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Mon, 30-Jun-86 09:53:00 EDT Article-I.D.: FIREBIRD.860630095315.5.DCP Posted: Mon Jun 30 09:53:00 1986 Date-Received: Mon, 30-Jun-86 18:09:23 EDT References: <860630094220.1.JOSEPH@HARLEM.SCRC.Symbolics.COM> Sender: jason@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa Date: Mon, 30 Jun 86 09:42 EDT From: Joseph R Goldstone TOPS-20 isn't the only SMTP server that is fussy about this. Even some Unix-based servers insist upon compliance to the spec here. Someone at a 4.2bsd site told me this "enforcement" took the form of many, many sendmail processes going into hard loops, pushing the load average up around 13 and chewing up more than 90% of the machine. The loopy processes have to be shot. He wasn't happy about it. (-: What a great way to bring down a Unix! :-) I assume he was less happy about the Unix software than he was about ours. Malformed data should elicit responses about malformed data. TOPS-20 did the right thing. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860630112339.8.PALTER%40LARRY-BIRD.SCRC.Symbolics.COM] <1986063007230000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Palter@SCRC-YUKON.ARPA (Gary M. Palter) Newsgroups: mod.protocols.tcp-ip Subject: failed mail from DCP Message-ID: <860630112339.8.PALTER@LARRY-BIRD.SCRC.Symbolics.COM> Date: Mon, 30-Jun-86 11:23:00 EDT Article-I.D.: LARRY-BI.860630112339.8.PALTER Posted: Mon Jun 30 11:23:00 1986 Date-Received: Tue, 1-Jul-86 03:42:40 EDT References: <12218271857.14.MRC@SIMTEL20.ARPA> Sender: daemon@styx.UUCP Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa Date: Fri 27 Jun 86 18:11:52-MDT From: Mark Crispin The problem is in the SMTP sender at the Symbolics end. There is a bogus space after "MAIL From:" before the "<" that begins the return path. RFC 821 is quite specific about where spaces are expected and where they are not expected. You cannot say "MAIL FROM: ", you must say "MAIL FROM:". TOPS-20 isn't the only SMTP server that is fussy about this. Even some Unix-based servers insist upon compliance to the spec here. ------- We fixed our mailer last week. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606301840.AA09205%40ucbvax.Berkeley.EDU] <1986063010463100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: craig@LOKI.BBN.COM (Craig Partridge) Newsgroups: mod.protocols.tcp-ip Subject: what to call the NIC Message-ID: <8606301840.AA09205@ucbvax.Berkeley.EDU> Date: Mon, 30-Jun-86 14:46:31 EDT Article-I.D.: ucbvax.8606301840.AA09205 Posted: Mon Jun 30 14:46:31 1986 Date-Received: Tue, 1-Jul-86 03:19:53 EDT Sender: daemon@styx.UUCP Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa There is already a top level domain for network support centers, NET. CS.NET is the domain for CSNET CIC support hosts. I'd argue the NIC should be something like NIC.DDN.NET (similar arguments can be made for the hosts at the NOC). Craig Partridge CSNET Technical Staff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606302158.AA12831%40ucbvax.Berkeley.EDU] <1986063011155000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MILLS@D.ISI.EDU Newsgroups: mod.protocols.tcp-ip Subject: Defective citation Message-ID: <8606302158.AA12831@ucbvax.Berkeley.EDU> Date: Mon, 30-Jun-86 15:15:50 EDT Article-I.D.: ucbvax.8606302158.AA12831 Posted: Mon Jun 30 15:15:50 1986 Date-Received: Tue, 1-Jul-86 04:02:31 EDT Sender: daemon@styx.UUCP Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa Folks, My thanks to Jon Postel, who pointed out my error in the author of thestory about the train with rubber tires. The story I was thinking of is called "Local Transportation in Surfcove," which can be found among the essays of Prof. J. Finnegan. Danny Cohen has collected many of these in his anthology "The World According to Finnegan." The story there concerns a train, sure enough, but not with rubber tires. My apologies to Prof. Finnegan and to Oceanview University, which some say can be found among the towers of Marina del Rey. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8606302206.AA07389%40nrl-aic] <1986063014060800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hemphill@NRL-AIC.ARPA (Gavin Hemphill) Newsgroups: mod.protocols.tcp-ip Subject: Am I imagining things? Message-ID: <8606302206.AA07389@nrl-aic> Date: Mon, 30-Jun-86 18:06:08 EDT Article-I.D.: nrl-aic.8606302206.AA07389 Posted: Mon Jun 30 18:06:08 1986 Date-Received: Tue, 1-Jul-86 04:06:51 EDT Sender: daemon@styx.UUCP Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa Sorry about the previous empty message -- fumble fingers strikes again. Is it my imagination or are other people experiencing problems as well. I have noticed lately that I can't FTP files bigger than 20 or 30 KB. The symptoms are that after 6 or 7 minutes (clock time) the FTP connections (to wherever from nrl-aic) break, there are no messages or indications from the remote server just the "ftp>" prompt. Secondary to this when I try to open a new connection to the same host I'll get the "host unreachable" message, but if I telnet to any other host -- and from there FTP or telnet to my original destination I can get through, and after backing out of that a direct FTP will again get through. Anybody else had similar problems? If so, any pointers would be appreciated. G++ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8607010122.AA29864%40cbosgd.ATT.COM] <1986063017220100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mark@cbosgd.att.com (Mark Horton) Newsgroups: mod.protocols.tcp-ip Subject: Re: HOSTS.TXT Message-ID: <8607010122.AA29864@cbosgd.ATT.COM> Date: Mon, 30-Jun-86 21:22:01 EDT Article-I.D.: cbosgd.8607010122.AA29864 Posted: Mon Jun 30 21:22:01 1986 Date-Received: Tue, 1-Jul-86 06:32:39 EDT Sender: daemon@styx.UUCP Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa >I'm not sure, however about the >restriction to two names -- some hosts have extra names for their plain >domain name (ucbvax.Berkeley.EDU -> Berkeley.EDU, etc.) ... > >As for SRI-NIC.ARPA -> NIC, maybe it should be NIC.ORG, It seems to me these are two examples of the same problem: a host which is organizationally three layers down in the tree, but which has responsibility for a higher level domain (Berkeley.EDU in the first case, ROOT in the second.) As such, I think the folks who run the machine should decide where to put the primary name (and I understand the NIC has chosen NIC.SRI.COM) with appropriate nicknames. Thus, the root (and also COM, EDU, and GOV) are in effect nicknames for the NIC. Whether they choose to support them as explicit nicknames is again up to them. Mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12219087923.5.MRC%40SIMTEL20.ARPA] <1986063018543900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MRC@SIMTEL20.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Am I imagining things? Message-ID: <12219087923.5.MRC@SIMTEL20.ARPA> Date: Mon, 30-Jun-86 22:54:39 EDT Article-I.D.: SIMTEL20.12219087923.5.MRC Posted: Mon Jun 30 22:54:39 1986 Date-Received: Tue, 1-Jul-86 18:40:33 EDT References: <8606302206.AA07389@nrl-aic> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa Gavin - You aren't the first person to have complained about this. I investigated it as a TOPS-20 problem but then I got reports that it happened in FTP transfers that didn't involve any TOPS-20 systems. I wish I knew what was the problem. -- Mark -- ------- ----MESSAGE-END----