|
|
ARCHIVE: TCP-IP Distribution List - Archives (1987)
DOCUMENT: TCP-IP Distribution List for May 1987 (243 messages, 110782 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1987/05.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Fri, 1-May-87 10:18:20 EDT From: stefan@wheaton.UUCP (Stefan Brandle) To: comp.protocols.tcp-ip Subject: need info about DECnet -- documentation and/or software
Our campus is getting DECnet'd, which is no doubt a good thing. The terminals will all eventually be going onto terminal servers -- also probably good, but it raises the question of what to do for computers not on DECnet. Specifically, we want to run BSD 4.3 on a uVAX. It has tcp/ip available, and a companion uVAX will be running Ultrix 2.0 w. DECnet. Now for the questions: 1) Anyone know of software that would allow the the terminal servers to contact the uVAX under 4.3? And other DEC machines not under DECnet? 2) Is technical documentation on DECnet available, or is that kept hush-hush? 3) Any suggestions on how we could write our own software to do this? File transfer (etc.) would be nice, but it is the terminal server stuff that is the big sticking point. Thanks for any answers. I'll summarize if there's interest. Stefan Brandle -- -------------------------------------------------------------------------------- Stefan Brandle UUCP: ihnp4!wheaton!stefan Wheaton College "But I never claimed to be sane!" ---------------------------------------------- MA Bell: (312) 260-4992 ---------
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Fri, 1-May-87 17:06:48 EDT From: karn@FLASH.BELLCORE.COM (Phil R. Karn) To: comp.protocols.tcp-ip Subject: Re: tcp smooth rtt function
My approach to the small-SRTT problem is to let it do what it wants, but bound the timer to the minimum non-zero value. I.e., if the clock ticks at a 1 Hz rate, rto = min(beta*srtt,1); /* rto is retransmission time-out */ Phil
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Sat, 2-May-87 02:10:46 EDT From: mike@BRL.ARPA (Mike Muuss) To: comp.protocols.tcp-ip Subject: Re: Ethernet Suffering
Two Sun-3/50 processors blasting to each other with a TCP connection can achieve ~2-3 Mbits/sec user-to-user throughput (tested with the TTCP program), and seem to use about 25% of the ethernet bandwidth as monitored on another Sun-3/50, which has unknown (to me) measurement accuracy. In our experiences this has had no noticable impact on other users of the Ethernet. Adding a second pair of Sun-3/50s running the same test doubled the loading on the Ethernet, as you would expect. Current wisdom suggests that there should be no more than one file server and 8 diskless Sun-3s per Ethernet for good Ethernet performance when all the Suns are busy. At BRL, we presently have one Ethernet with 14 Sun-3/50s and and 4 Sun-2/50s running off of one fileserver (a Gould PN9050 giving both ND and NFS service), as well as a variety of other machines (more Goulds and 2 Alliant FX/8s) that communicate with NFS on a more occasional basis. We find that head contention on the file server is the performance limit now, not the Ethernet. However, once the filesever is beefed up a bit, the Ethernet will be next, so the Ethernet will be split into two, with a pair of level-3 IP gateways between them. Hope this information helps. Best, -Mike
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Sat, 2 May 87 07:03:35 EDT From: jqj@gvax.cs.cornell.edu (J Q Johnson) To: arpa.tcp-ip Subject: Re: Ethernet Suffering
Charles Hedrick notes that 20 to 40 diskless SUNs is a resonable load on an Ethernet. Although our experience at Cornell is consistent with this estimate, one should be a bit careful: small software and usage changes can make for big changes in behavior. For example, on our main Ethernet (about 25 diskless SUNs plus 75 other machines, total less than 25% load) we observe that at least 1/2 of the SUN load is ND traffic. ND is not efficient in its use of Ethernet bandwidth, and I would expect the total load offered by the SUNs to drop, perhaps precipitously, when SunOS4.0 arrives. Similarly, slightly better caching strategies in clients can make a big difference, as can adding a bit more memory (we do wish our 3/50s had 6MB!). Perhaps most important, don't attempt to generalize from diskless SUNs to PC-ATs (or even to diskless VAXstations). The PCs won't be paging across the network, don't run a multitasking OS, have typically smaller program sizes than Suns and longer process lifetimes, etc. All the above points to being able to support lots of diskless workstations on your network. On the other hand, it would be foolish to design a network that didn't make provisions for saturation. If you don't put in bridges or gateways initially, at least locate your servers near their clients so you can get the benefit of installing bridges later if you need to. Leave your PCs with a couple of empty slots so you can add more memory (for a RAM disk or whatever) later if need be. And so on. Don't assume that any load analysis you do today will still be valid in 1989.
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Sat, 2-May-87 10:42:00 EDT From: Kodinsky@MIT-MULTICS.ARPA To: comp.protocols.tcp-ip Subject: Re: tcp/ip/IBM/ProNET
Speeds iun excess of 100 Kbytes/Second are not unheard of for TCP/IP on
VM. Using KNET/VM on a VM system (true it is a 3090/200) I have seen
speeds peak at about 150 Kbytes/sec. With averages about 85 or 90.
Also, this was not sunday mornging, but the middle of a weekday
afternoon. Other KNET/VM users have reported peaks above 100 Kbytes/sec
Also at spartacus we have peaked at about 55 Kbytes per secoond -
running on a Nixdorf 8890/50 (4331 level machine) and all of our
terminals and disk drives on the same channel - and only one head of
string unit for our disks (for the non S/370 people read that as
extreeeeeemellly sloooooooowwwwwwww).
Now I admit a biased point of view (I am the KNET/VM Development
Manager) and the above is not the full story - on our system during the
middle of the day at abd load times (command response times on the order
of 10's of seconds) I have seen rates drop below 1Kb/second.
My point is that 100KB/Sec has been broken, with production, generally
available products, on production systems experiencing production loads
(not overloads!!!!!).
One final caveat - the speeds that other KNET users may see depend on
many variables and the above speeds should not be used as a guarantee of
the speeds you see ("The milage you get may vary....").
Frank Kastenholz Manager, KNET/VM Development Spartacus/Fibronics
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Sun, 3-May-87 14:47:08 EDT From: steve@BRILLIG.UMD.EDU (Steve D. Miller) To: comp.protocols.tcp-ip Subject: Net Unreachable versus Host Unreachable
I noticed yesterday that ucbvax was sending me Net Unreachable messages for hosts on a subnet of ucb-ether, although ucb-ether itself was indeed reachable. Since I don't know that ucb-ether is subnetted (well, OK, I know, but my kernel doesn't), I could make wrong decisions based on that information. This seemed wrong to me, so I added a quick hack to the 4.3 ip_forward() so that, when ip_output() returns ENETUNREACH or ENETDOWN, it checks to see if the destination address of the unforwardable packet is on a known subnetted network, and sends a Host Unreachable message (instead of a Net Unreachable message) if the destination network is indeed subnetted. I then started thinking about the suggestion in RFC 985 that states that, because subnetting information isn't visible outside the subnetted network, Host Unreachable messages should always be sent in the place of Network Unreachable messages. However, it seems to me that the entity sending the unreachability message will fall into one of the following two classes: 1) The entity is a gateway for the destination network, and as such should either know the subnetting scheme for the network or should forward the packet to another gateway with such knowledge. In this case, I think that the Host Unreachable message should be used so that false unreachability information doesn't creep out onto the network. 2) The entity is a gateway that knows (inasmuch as anything ever does) that the entire destination network is down. In this case, the Network Unreachable message should be sent, since this message in this case conveys the maximum amount of correct information. Since it seems to me that there is no ambiguity here, and since there might be software Somewhere Out There that can use the Network Unreachable information to avoid sending extra packets out onto the Internet, it might be better to follow the scheme above. In fact, the reason that I stumbled across this behavior is because I'm testing such an application (the ICMP caching beast I described a few months ago). Does this scheme make sense to everyone, or am I missing something obvious? -dateat
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Sun, 3-May-87 19:18:00 EDT From: rms@ACC-SB-UNIX.ARPA (Ron Stoughton) To: comp.protocols.tcp-ip Subject: re: tcp/ip/IBM/ProNET
I would like to comment briefly on David Young's suggestion and John Shriver's reply regarding using ACS 9310's and a ProNET gateway to interface an IBM system to ProNET. The purpose here is not to beat our chest, but to clarify what the 9310 can and cannot do. First, there was an inference that the ACS 9310 could run at the full speed of the Ethernet. As John correctly pointed out, this is not quite true, or is at least misleading. While it is true that the channel interface will run at the full speed of the block multiplexer channel, and the Ethernet interface will run at the full 10Mbps speed of the Ethernet, the *sustained* throughput capacity is somewhat less. We have measured a sustained packet rate of 3600+ packets/sec at the channel interface, and 2700+ packets/sec at the Ethernet interface. However, the software glue which binds these together drops the total capacity to 350 packets/sec (it's amazing what programmers can do). One should note that the main bottleneck is the memory-to-memory transfer rate across an internal system bus which interconnects these two subsystems. Incorporating a hardware DMA would significantly improve system throughput. [I should point out that the 9310 does more than just simple pass-through between the channel and the network. For example, all ARP processing is done in the interface, and for historical reasons, IMP emulation is performed there as well.] Second, whether or not the 9310 is faster than the DACU (it is) should not be the only consideration. In particular, the effi- ciency of the channel protocol can significantly impact system performance. I am not intimately familiar with the DACU, but I believe it emulates 3250 commands to transfer data. Like other IBM control units, this is half-duplex and requires attention interrupts. The 9310 uses two independent subchannels to provide a full-duplex interface. Someone in our office once looked at some code which interfaced to a DACU and counted 10 channel inter- actions to transfer some data and read a response. Hopefully the Wiscnet driver was not done in this manner, but nevertheless, a halfduplex interface will certainly result in more interrupts. Third, John's assertion that even if the hardware could run at the full speed of the network that the host software could not, is certainly true. However, I do not agree that the 100Kbytes/sec barrier has not been broken or threatened. Lacking anything faster than a VAX 750, we did some file transfers to ourselves (a 4341-2 running ACCES/MVS) by looping within the 9310. We measured 50K bytes/sec in each direction. While this is not a 100kbytes/sec file transfer, it is exactly equivalent to two simultaneous 50K bytes/second transfers, or an aggregate of 100Kbytes/sec through TCP/IP and FTP. It should also be pointed out that the 9310 averaged less than 40% busy which is consistent with its 350 packets/second capacity. Extrapolating, and assuming no coalesc- ing of TCP acks, it should be possible to transfer an aggregate of 262Kbytes/sec. In an attempt to find out why we could not drive the 9310 to saturation we repeated the above tests, but looping at the EXCP level instead of in the 9310. In otherwords, output packets were copied from the output buffer into an input buffer instead of being transferred across the channel (to the 9310). Even with the additional buffer copy, we measured an aggregate of 260Kbytes/sec. The difference (160Kbytes/sec) is apparently attributable to IOS interrupt processing and MVS dispatching overhead. This was surprising to me, but not inconsistent with MVS's reputation of being an I/O klutz, particularly on small mainframes. Additional interrupt processing because of half-duplex handshaking would only make matters worse. I tend to agree with John that we should avoid benchmark wars since the numbers are often meaningless without proper context. Also, such tests are often conducted under optimum conditions which may not apply to the garden variety file transfer. For example, rates are usually quoted for binary transfers, whereas most file transfers are in ASCII. In regard to using a 9310 + ProNET gateway to interface a VM system to ProNET-80, our sales people are certainly not going to refuse to take your money. However, I am not sure the performance benefits are necessarily acheivable at this time. For example, what is the performance threshold of the Wiscnet software, and what is at the other end of the network connection (you can't send data faster than the other end is willing to receive it)? The deciding factor may be the amount of CPU resources a user is willing to expend to acheive a given level of throughput. Some more definitive information may be forthcoming. We are having a new driver developed for Wiscnet which should be much more efficient than the driver which comes with 5798-DRG (or now 5798-FAL). As part of this effort some benchmarking will be done. Anyone interested in the results should contact me and I will send you the information. If I have offended anyone's sensibilities by appearing commercial, I apologize. This was not the intent. Ron Stoughton ACC
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Mon, 4-May-87 10:58:00 EDT From: dms@HERMES.AI.MIT.EDU (David M. Siegel) To: comp.protocols.tcp-ip Subject: Ethernet Suffering
Here at the MIT AI Lab we have found that our diskless sun workstations put a much heavier load on an Ethernet than Hedrick and Johnson noted. Using a network analyzier, the 18 diskless Suns we have on one ether can run the cable at 50 percent of capacity for extended periods of time. Peek 5 second usage often jumps to 70 percent. All our machines have 8 Meg of RAM, though some of them run Sun Common Lisp. Much of the traffic is ND packets. Based on this, we are planning on having no more than 12-15 Suns are one ethernet. Each server will have its own "client" subnet.
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Mon, 4-May-87 16:50:06 EDT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: An old ticker fades away
Folks, It has become necessary to discontinue TCP/TIME service in the various fuzzballs scattered over the known universe. The UDP-based services UDP/NTP (see RFC-958) and UDP/TIME will continue ticking indefinately. As mentioned several times to this list over the last few years, TCP/TIME happens to be rather resource-intensive in the fuzzball implementation as compared with other services usually considered more vital. The UDP-based services are much more accurate and less intrusive. Dave
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Mon, 4-May-87 18:09:49 EDT From: timk@babbage (Tim Krauskopf, NCSA) To: comp.protocols.tcp-ip Subject: Re: PC/IP problem
---------------------------------------------
From Tim Krauskopf, NCSA:
In response to the screen blank out problem with PC/IP.
I felt that I should comment on this because I am probably the only person
to ever patch the PC/IP program to take care of this problem without
recompiling -- it is possible to patch the .COM file.
The problem is that the PC/IP scrolling routines use the little-known
hardware scrolling feature of the first two video adapters available from
IBM. If you poke the correct registers, you can change the memory byte
address which the adapter uses for the upper left corner of the screen.
At the end of the memory buffer, 4K for the monochrome, 16K for the color,
the video controller will "wrap-around" to the beginning of the RAM buffer
when it displays the screen.
The problems occur when using "Print-screen" and the newer video adapters.
Print-screen starts at the beginning of the buffer, no matter where the
video controller thinks the beginning of the screen is. PC/IP added the
F10/F10 command to copy the contents of the video screen back to the
beginning of the buffer, for use with print-screen. With the EGA and
other video adapters, there is more than 16K of memory, and the hardware
wrap-around feature does not exist, though the hardware scroll feature
still does. When PC/IP reaches the end of the 16K of memory that it
thinks it is using, it wraps back to zero, but the EGA keeps going -- it
has 32K or more to use. The result, a blank screen until F10/F10 restores
it. The fix: patch out their scroll routines with the BIOS ones.
Sorry to bother those of you who don't care, but this fix is quick,
so . . . to fix this problem in the latest release (Mar 86):
Use debug on telnet.com, at offset AD15:
-a ad15
cs:AD15 MOV AX,0601
XOR CX,CX
MOV DX,174F
MOV BH,07
INT 10
XOR BX,BX
JMP AD3A
-a AD75
cs:AD75 MOV AX,0701
XOR CX,CX
MOV DX,174F
MOV BH,07
INT 10
XOR BX,BX
JMP AD9D
-w
-q
It worked for me.
Tim Krauskopf
National Center for Supercomputing Applications (NCSA)
University of Illinois
timk%newton@uxc.cso.uiuc.edu (ARPA)
14013@ncsavmsa (BITNET)
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Mon, 4-May-87 23:45:47 EDT From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) To: comp.protocols.tcp-ip Subject: Re: Ethernet Suffering
Note that the 2-3 Mbits/sec of Ethernet traffic you report is with a test program designed to test the network only. However in actual use, the majority of the high-speed Ethernet traffic is generated by file serving. In that case, it is limited by the speed the disks, and the amount of lookahead done by the protocols. I would be extremely surprised to see the current generation of Sun file server deliver more than 1Mbit/sec of sustained throughput. Much to my surprise, I find that replacing Eagles with super-Eagles does not seem to increase the throughput available in my tests noticably. Note that these tests involved a mix of operations, including file creating, reading, removing, and renaming, and that the files were small or moderate in size. I.e. we tried to duplicate the sorts of I/O that a typical student mix would generate. I have to believe that fast sequential operations on large files would get more with a super-Eagle. Some other results: - one Eagle with one controller seemed to use about 2/3 of the CPU in a 3/180. - a second Eagle on the same controller added very little in throughput - a second Eagle on a second controller added about 50% in capacity. It seems that this was limited by CPU capacity - a 280 with super-Eagle did not have noticably more performance than a 180 with Eagle. However we assume that the 280 would be able to handle two disks and controllers without running out of steam. (We were unable to test this because we didn't have the right hardware configuration.) It's not clear whether this would be cost-effective, though, when compared against using one Sun 3/140S per disk [a configuration which however is not supported by Sun. Indeed I'm not sure that the 140S is even on the price sheet.]I wgets
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Tue, 5-May-87 03:44:51 EDT From: mike@BRL.ARPA (Mike Muuss) To: comp.protocols.tcp-ip Subject: Re: Ethernet Suffering
I agree that the TTCP only measured memory-to-memory throughput. That was the intent -- to see how much data could be shoveled. I did not intend to suggest it was a generic benchmark. Note that TTCP was using TCP, mind you, not NFS or ND. In our environment, we do a lot of network-based 24-bit RGB graphics, which means whacking .75Mbytes (lores) or 3 Mbytes (hires) for each image. Often they are computed and displayed without ever touching a disk. So the TTCP test was not uninteresting. Our Gould 9000 fileserver, which serves the collection of Suns I mentioned, can be seen at busy times handling 200 packets/second in both the transmit and receive directions (peak). Many of them result in disk transactions, although the ratio can be deceptive. Eg, 1 pkt arrives asking for 8kbytes of data, which is read with one disk I/O, and returned in 8 packets. 1 disk I/O, 9 packets. Hope you find these random statistics of interest. Best, -M
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Tue, 5-May-87 21:15:08 EDT From: martillo@ATHENA.MIT.EDU To: comp.protocols.tcp-ip Subject: Ethernet Terminal Concentrators
Does anybody have figures for obtained packet rates for asynchronous terminal concentrators over ethernet? I mean the configuration where the host has an ethernet interface and lives on the same LAN as the asynchronous terminal concentrator which supports say 8-16 terminals. I think DEC has a product of this type called LAT (LAN Asynchronous Terminal?). I would suspect that because protocol layers 3 and 4 would not need to be implemented that better performance would be obtained than with telnet or rlogin based terminal concentrators (although internetting would be impossible). I would still be interested in figures for telnet or rlogin style terminal concentrators as well. Also while the maximum packet rate at the concentrator is of interest, I would really like to know what sort of packet rates people consider good on the host side. Yakim Martillo
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Wed, 6-May-87 04:15:08 EDT From: root@TOPAZ.RUTGERS.EDU (Charles Hedrick) To: comp.protocols.tcp-ip Subject: Re: Ethernet Terminal Concentrators
I just took a look at some statistics from three of our Cisco terminal servers. Since it's 3am, packet rates wouldn't show much, but I have some other data which is probably in the long run more useful. This shows the total number of packets in and out for each session, the total number of bytes, and the number of packets with data. By looking at the fraction of packets with data, you can get a feeling for how much you are paying for TCP ack and window updates. Note however that even with LAT, there surely has to be some sort of acknowledgements, so it can't be 100% efficient either. The original data contains a lot more info about the innards of the TCP protocol handling, but I have omitted it as it didn't seem relevant to this discussion. It looks like well over half (typically over 2/3) of the packets received have data (i.e. are not just acks), and the amount of data per packet is fairly high. It looks like around half, or maybe slightly less of the packets sent have data, and as you would expect it is about one char per packet. (A couple of the connections have been idle for long periods, so you see packets that aren't doing much.) It looks to me like this is about as efficient as one can hope for. It looks like acks for stuff we send typically gets piggybacked on the echo, but the stuff that comes back requires separate acks. This is what you'd expect with a simple model of what is going on, and is presumably going to be the same for any protocol that is designed to use unreliable networks. The number of characters per packet also seems good. Obviously I can't compare this with LAT without seeing data on LAT, but there doesn't seem to be a lot of room for improvement. dialup to Sun (4.2 IP, 4.3 beta TCP), though one gateway Rcvd: 4694 (out of order: 0), with data: 4374, total data bytes: 160181 Sent: 6456 (retransmit: 1), with data: 3988, total data bytes: 4220 dialup to Pyramid (4.3 TCP/IP, with telnetd in the kernel) Rcvd: 1981 (out of order: 0), with data: 1634, total data bytes: 119314 Sent: 1626 (retransmit: 0), with data: 824, total data bytes: 900 hardwired to Sun, through one gateway Rcvd: 2472 (out of order: 0), with data: 1265, total data bytes: 114771 Sent: 2489 (retransmit: 0), with data: 175, total data bytes: 191 hardwired to Pyramid Rcvd: 12195 (out of order: 0), with data: 7116, total data bytes: 88935 Sent: 9044 (retransmit: 0), with data: 6957, total data bytes: 7206 hardwired to Sun, through one gateway Rcvd: 671 (out of order: 0), with data: 406, total data bytes: 10684 Sent: 834 (retransmit: 0), with data: 340, total data bytes: 349 hardwired to DEC-20 Rcvd: 14579 (out of order: 0), with data: 410, total data bytes: 54371 Sent: 492 (retransmit: 0), with data: 207, total data bytes: 249
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 May 87 10:54:11 PDT From: nagle@cdrsun.stanford.edu (John B. Nagle) To: TCP-IP@NIC.SRI.COM Subject: Remote printer server for IBM VM systems?
Does there exist software for IBM VM systems that will allow such
systems running the Wisconsin TCP/IP software to act as remote printers for
other systems? If you've got something, please let me know.
John Nagle
Center for Design Research, Stanford
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: 6 May 87 08:35:00 EDT From: "MAARTEN NEDERLOF" <salomon@wharton-10.arpa> To: "tcp-ip" <tcp-ip@sri-nic.arpa> Subject: Ethernet Remote Bridge query...
I've been noticing that messages of late seem to be dealing with the topic of Ethernet performance under a large number of diskless workstations, and the like, and it prodded me to ask my question here, even though my needs are not specifically TCP-IP. We have the need for a remote bridge that can channel as much of the full bandwidth of a baseband Ethernet as possible. We have seen remote microwave bit repeaters, but the distance we are considering is about 9 miles, and regardless of the communications medium, light isn't fast enough to allow us to maintain one segment. Does anyone in this forum have any information on a bridge that can use a 10MB communications channel (carved from a T3 line) and still give us minimal timing delay end to end across it? We have an Ethernet based image transfer system that is highly sensitive to timing delays on the network, so relay speed is of the essence. Any recommendations or comments would be appreciated. Maarten Nederlof Salomon Brothers Inc. SALOMON@WHARTON-10.ARPA ------
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Wed, 6-May-87 13:54:11 EDT From: nagle@CDRSUN.STANFORD.EDU.UUCP To: comp.protocols.tcp-ip Subject: Remote printer server for IBM VM systems?
Does there exist software for IBM VM systems that will allow such
systems running the Wisconsin TCP/IP software to act as remote printers for
other systems? If you've got something, please let me know.
John Nagle
Center for Design Research, Stanford
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Wed, 6-May-87 13:54:12 EDT From: hedrick@TOPAZ.RUTGERS.EDU.UUCP To: comp.protocols.tcp-ip Subject: off RIP packet
Our Arpanet gateway, 10.1.0.89, is receiving RIP (Unix routed) packets from 26.12.0.122. This seems to have started yesterday. Initially, the packets caused our routing tables to get into a loop. However I have now fixed things so that we ignore them. But does anybody know what is going on? We are still receving them. I sent something to root at that site and haven't yet gotten an answer. The site seems to be using the Wollongong System V TCP/IP implementation. It is possible that the packets are arriving via either Arpanet or NSFnet. However a packet watch on the NSFnet side suggests that they are not coming that way. (Unfortunately I have no way to do packet watches on the Arpanet side.) Normally RIP packets are broadcast on all connected Ethernet interfaces. I thought the Arpanet didn't do broadcasting, and that broadcasts certainly wouldn't go through the "mail bridges" between 26 and 10. Am I wrong?
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Wed, 6-May-87 13:56:00 EDT From: CERF@A.ISI.EDU.UUCP To: comp.protocols.tcp-ip Subject: Re: Ethernet Terminal Concentrators
Yakim, LAT stands for the name of the protocol used by Digital to support terminal to host access over an ethernet. Dunno what rates you can expect, but we were supporting 35-50 concurrent virtual terminals from a microvax II across an ethernet to a bunch of hosts. Oh, each VT was operating between 1200 and 2400 bps but the protocol to the microvax was line at a time X.25. Vint
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 6 May 1987 13:56-EDT From: CERF@A.ISI.EDU To: martillo@ATHENA.MIT.EDU Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: Ethernet Terminal Concentrators
Yakim, LAT stands for the name of the protocol used by Digital to support terminal to host access over an ethernet. Dunno what rates you can expect, but we were supporting 35-50 concurrent virtual terminals from a microvax II across an ethernet to a bunch of hosts. Oh, each VT was operating between 1200 and 2400 bps but the protocol to the microvax was line at a time X.25. Vint
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Wed, 06 May 87 16:54:53 +0100 From: Jon Crowcroft <jon@Cs.Ucl.AC.UK> To: tcp-ip@sri-nic.arpa Subject: Ethernet Suffering
The figures here are approx: Manchester University run a net of 60 odd suns. They have 10 diskless 3/50s per 3/260 server with a 400 Mb eagle. Each server-client set has it's own thin ethernet. All the servers are backboned on an ethernet. with 4Meg on each diskless client, 8 Meg on server, the servers and ethernet just about cope if no more than 5Meg virtual mem is used in each client (ie 1Meg swapping). I don't know whether the bottleneck is ethernet or server cpu/disk speeds. Most of the ether traffic is ND/NFS, which is much less a respecter of bandwidths and delays than tcp traffic, and wreaks havoc with bridges and gateways unless you handwind down the read/write transfer sizes. Hence the client/server ratio and separate ethers. Does anyone know of any affordable ethernet/ethernet IP gateway/subnet router that can take 8 Kbytes worth of IP back to back from several (~10) hosts at once? Jon
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: Wed, 6-May-87 23:57:49 EDT From: karn@FLASH.BELLCORE.COM.UUCP To: comp.protocols.tcp-ip Subject: question about FTP data channels
Question: what assumptions may an FTP client make about the address and port (i.e., socket) that will be used when the server opens a data connection? When my implementation sends a RETRieve command, it posts a listen for the data connection. Rather than accepting anyone who connects, it listens specifically for a SYN carrying the IP address of the server, and TCP port 20. This works fine except in the case of a multi-homed FTP server. If I have established my control connection to the "far side" IP address, many such hosts will use the IP address associated with the "nearer" interface when initiating the data channel, and my TCP will refuse it. I guess I'm answering my own question here, namely that I have to be prepared to accept any IP address in the incoming connection, since I have no way of knowing if the server will use an address different than the one I used on the control connection. Comments? Phil
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Thu, 7-May-87 01:50:34 EDT From: jon@CS.UCL.AC.UK.UUCP To: comp.protocols.tcp-ip Subject: Ethernet Suffering
The figures here are approx: Manchester University run a net of 60 odd suns. They have 10 diskless 3/50s per 3/260 server with a 400 Mb eagle. Each server-client set has it's own thin ethernet. All the servers are backboned on an ethernet. with 4Meg on each diskless client, 8 Meg on server, the servers and ethernet just about cope if no more than 5Meg virtual mem is used in each client (ie 1Meg swapping). I don't know whether the bottleneck is ethernet or server cpu/disk speeds. Most of the ether traffic is ND/NFS, which is much less a respecter of bandwidths and delays than tcp traffic, and wreaks havoc with bridges and gateways unless you handwind down the read/write transfer sizes. Hence the client/server ratio and separate ethers. Does anyone know of any affordable ethernet/ethernet IP gateway/subnet router that can take 8 Kbytes worth of IP back to back from several (~10) hosts at once? Jon
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Thu, 7-May-87 08:42:00 EDT From: SYSTEM@CRNLNS.BITNET.UUCP To: comp.protocols.tcp-ip Subject: Re: Ethernet Terminal Concentrators
Charles,
Thanks for the Ethernet utilization statistics for your Cisco
terminal servers. It's consistant with what I've seen for
one host based TELNET program.
Unfortunately, though, it's not the whole story.
The problem that we've encountered is the high
CPU overhead used by at least one TELNET implementation under VMS.
I am enclosing a copy of a brief test that I did recently.
It's certainly not definitive, but it gives one food for thought.
Selden E. Ball, Jr.
(Wilson Lab's network and system manager)
Cornell University NYNEX: +1-607-255-0688
Laboratory of Nuclear Studies BITNET: SYSTEM@CRNLNS
Wilson Synchrotron Lab ARPA: SYSTEM%CRNLNS.BITNET@WISCVM.WISC.EDU
Judd Falls & Dryden Road PHYSnet/HEPnet/SPAN:
Ithaca, NY, USA 14853 LNS61::SYSTEM = 44283::SYSTEM (node 43.251)
P.S. The Ethernet utilization figures were obtained by running
a patched version of VMS Monitor with the command
$ MONITOR ETHERNET
I can send you a copy of the patch if you don't have it.
S.
-------------------------------------------------------------------
The following is a report of a test done using CMU/TEK TCP/IP
by S.Ball on April 23rd and 24th, 1987
Executive summary:
=================
If we run TCP/IP for production use, we will need a front end.
CMU/TEK TCP/IP software uses an excessive amount of cpu resources
for terminal support both outbound, when accessing another system,
and inbound, when the local system is hosting a session.
Environment:
============
2 VAX-11/750s (LNS53 and CLE750) with FPA and 5 Megabytes of memory,
running VMS 4.4 and connected with DEUNA Ethernet interfaces.
The CMU TCP/IP package being tested consisted of
FINGER V2.4, SMAIL V2.5, TELNET V3.0, and IP/ACP V6.0.
Only TELNET and IP/ACP were actually involved in this test.
Each of the tests was run for only about a minute, so the percentages
aren't accurate to better than about 5% or worse.
Unfortunately, that size of error is unimportant.
TELNET i/o test
---------------
I used a 9600 baud terminal connected to a DEC LAT-11 terminal server
on Ethernet. Past studies have shown the LAT protocol to be
comparable to DMF-32 connections in terms of its CPU use.
First I logged into LNS53 (3 others were logged in doing nothing),
and then did a TELNET to CLE750 (where 1 other was logged in doing nothing)
and gave the command "TYPE DOC:*.*;*". Our DOC: directory contains
many text files of various sizes.
results:
--------
(the actual numbers fluctuated +/- 5% or so, presumably due to disk
file open overhead)
The transfer used 100% of the cpu on (remote) CLE750
====
(20% kernel, 80% user, <5% interrupt)
User mode programs on on CLE750 were the TELNET server using about 50%,
IP_ACP using about 15%, and TYPE using about 15%.
It used 50% of the cpu on (local) LNS53 (15% kernel, 35% user, <5% interrupt)
===
User mode programs on LNS53 were TELNET and IP_ACP, using approximately
equal fractions of the cpu, but with large fluctuations.
Ethernet use went from 10Kbytes/sec to about 15Kbytes/sec.
The Ethernet packet size averaged about 100 bytes,
presumably 1 per record of terminal output.
But, if we assume half of the i/o increase was Lat from LNS53 to the
LAT-11, and half was TELNET from CLE750 to LNS53, this implies, since
the terminal i/o was < 1 Kbyte/sec x 2 = < 2 Kbytes/sec, that there was
> 3 Kbytes/sec of overhead somewhere. Some of the excess may
have been due to other systems doing Ethernet i/o at the same time.
For comparison:
==============
Using DECnet SET HOST
---------------------
I used the same 9600 baud terminal connected to a DEC LAT-11
terminal server on Ethernet.
I logged into LNS53 (1 other user was running a cpu bound job),
I did a SET HOST to CLE750 (where 1 other was logged in doing nothing),
and used the command "TYPE DOC:*.*;*"
On LNS53, there was no observable degredation in my terminal output
due to the other job, but the other job averaged > 75% of the cpu.
In contrast to TELNET use, CLE750 averaged > 85% idle.
Kernel and Interrupt modes fluctuated from 2% to 10% each,
apparently dominated by disk file open operations.
Unfortunately, the increased load on Ethernet wasn't observable:
it was already fluctuating between 35 and 45 Kbytes/sec.
Using a direct LAT connection
-----------------------------
Again I used the 9600 baud terminal connected to a DEC LAT-11 terminal
server on Ethernet.
I logged into CLE750 (there was 1 other user logged in doing nothing),
and gave the command "TYPE DOC:*.*;*"
CLE750 averaged > 85% idle.
Kernel and Interrupt modes fluctuated from 2% to 10% each,
apparently dominated by disk file open operations.
Ethernet use went from about 11 Kbytes/sec to maybe 12.5 Kbytes/sec.
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 May 87 08:42 EDT From: <SYSTEM%CRNLNS.BITNET@wiscvm.wisc.edu> To: TCP-IP@SRI-NIC.ARPA Subject: Re: Ethernet Terminal Concentrators
Charles,
Thanks for the Ethernet utilization statistics for your Cisco
terminal servers. It's consistant with what I've seen for
one host based TELNET program.
Unfortunately, though, it's not the whole story.
The problem that we've encountered is the high
CPU overhead used by at least one TELNET implementation under VMS.
I am enclosing a copy of a brief test that I did recently.
It's certainly not definitive, but it gives one food for thought.
Selden E. Ball, Jr.
(Wilson Lab's network and system manager)
Cornell University NYNEX: +1-607-255-0688
Laboratory of Nuclear Studies BITNET: SYSTEM@CRNLNS
Wilson Synchrotron Lab ARPA: SYSTEM%CRNLNS.BITNET@WISCVM.WISC.EDU
Judd Falls & Dryden Road PHYSnet/HEPnet/SPAN:
Ithaca, NY, USA 14853 LNS61::SYSTEM = 44283::SYSTEM (node 43.251)
P.S. The Ethernet utilization figures were obtained by running
a patched version of VMS Monitor with the command
$ MONITOR ETHERNET
I can send you a copy of the patch if you don't have it.
S.
-------------------------------------------------------------------
The following is a report of a test done using CMU/TEK TCP/IP
by S.Ball on April 23rd and 24th, 1987
Executive summary:
=================
If we run TCP/IP for production use, we will need a front end.
CMU/TEK TCP/IP software uses an excessive amount of cpu resources
for terminal support both outbound, when accessing another system,
and inbound, when the local system is hosting a session.
Environment:
============
2 VAX-11/750s (LNS53 and CLE750) with FPA and 5 Megabytes of memory,
running VMS 4.4 and connected with DEUNA Ethernet interfaces.
The CMU TCP/IP package being tested consisted of
FINGER V2.4, SMAIL V2.5, TELNET V3.0, and IP/ACP V6.0.
Only TELNET and IP/ACP were actually involved in this test.
Each of the tests was run for only about a minute, so the percentages
aren't accurate to better than about 5% or worse.
Unfortunately, that size of error is unimportant.
TELNET i/o test
---------------
I used a 9600 baud terminal connected to a DEC LAT-11 terminal server
on Ethernet. Past studies have shown the LAT protocol to be
comparable to DMF-32 connections in terms of its CPU use.
First I logged into LNS53 (3 others were logged in doing nothing),
and then did a TELNET to CLE750 (where 1 other was logged in doing nothing)
and gave the command "TYPE DOC:*.*;*". Our DOC: directory contains
many text files of various sizes.
results:
--------
(the actual numbers fluctuated +/- 5% or so, presumably due to disk
file open overhead)
The transfer used 100% of the cpu on (remote) CLE750
====
(20% kernel, 80% user, <5% interrupt)
User mode programs on on CLE750 were the TELNET server using about 50%,
IP_ACP using about 15%, and TYPE using about 15%.
It used 50% of the cpu on (local) LNS53 (15% kernel, 35% user, <5% interrupt)
===
User mode programs on LNS53 were TELNET and IP_ACP, using approximately
equal fractions of the cpu, but with large fluctuations.
Ethernet use went from 10Kbytes/sec to about 15Kbytes/sec.
The Ethernet packet size averaged about 100 bytes,
presumably 1 per record of terminal output.
But, if we assume half of the i/o increase was Lat from LNS53 to the
LAT-11, and half was TELNET from CLE750 to LNS53, this implies, since
the terminal i/o was < 1 Kbyte/sec x 2 = < 2 Kbytes/sec, that there was
> 3 Kbytes/sec of overhead somewhere. Some of the excess may
have been due to other systems doing Ethernet i/o at the same time.
For comparison:
==============
Using DECnet SET HOST
---------------------
I used the same 9600 baud terminal connected to a DEC LAT-11
terminal server on Ethernet.
I logged into LNS53 (1 other user was running a cpu bound job),
I did a SET HOST to CLE750 (where 1 other was logged in doing nothing),
and used the command "TYPE DOC:*.*;*"
On LNS53, there was no observable degredation in my terminal output
due to the other job, but the other job averaged > 75% of the cpu.
In contrast to TELNET use, CLE750 averaged > 85% idle.
Kernel and Interrupt modes fluctuated from 2% to 10% each,
apparently dominated by disk file open operations.
Unfortunately, the increased load on Ethernet wasn't observable:
it was already fluctuating between 35 and 45 Kbytes/sec.
Using a direct LAT connection
-----------------------------
Again I used the 9600 baud terminal connected to a DEC LAT-11 terminal
server on Ethernet.
I logged into CLE750 (there was 1 other user logged in doing nothing),
and gave the command "TYPE DOC:*.*;*"
CLE750 averaged > 85% idle.
Kernel and Interrupt modes fluctuated from 2% to 10% each,
apparently dominated by disk file open operations.
Ethernet use went from about 11 Kbytes/sec to maybe 12.5 Kbytes/sec.
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Thu, 7-May-87 09:28:24 EDT From: swb@DEVVAX.TN.CORNELL.EDU.UUCP To: comp.protocols.tcp-ip Subject: off RIP packet
When we first put together the gatedaemon we discovered people sending RIP packets point-to-point over Arpanet and Milnet. I believe they were EGPing with a core gateway or two, and *in addition* sending point-to-point RIP packets to all of the thus-discovered external gateways, just to be sure packets to them would not go through an extra hop. Scott
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: 7 May 87 17:41:00 PST From: <art@acc.arpa> To: "tcp-ip" <tcp-ip@sri-nic.arpa> Cc: ineng-tf@gateway.mitre.org Subject: More on TCP timers
With the recent discussion of TCP retransmission timers, I thought that I would add my two cents worth. I have been looking at the the behavior of TCP on low speed (9600 baud), low delay (IMP-and-back or point-to-point) links. The usual timing algorithms: srtt = alpha*srtt + (1-alpha)rtt [alpha approx. .9] rx_timeout = beta*srtt [beta approx. 2] seem to be oriented to an environment where the round trip delay is smoothly changing and has LOW VARIANCE. I believe that neither of these points is really true in the internet. Also, most TCP implementations assume that the measurement of rtt is INDEPENDENT of MESSAGE SIZE. This is definitely NOT true in the situations I have been looking at. My model of network delay has three components: 1) Inherent or Minimum Delay (speed of light, packet processing times) 2) Queueing or Waiting Times (at link level or in gateways) 3) Transmission Times (how long it takes to send at link level) Part 1 should be relatively constant over a path between two end points. Part 2 is where congestion shows up. Part 3 is DIRECTLY RELATED to PACKET SIZE. I believe that Part 1 is generally insignifcant except for satellite hops. Part two is related to congestion and is usually affected by Part 3. Part 3 is insignificant for high speed LANs, BUT NOT WHEN LOW SPEED LINKS ARE TRAVERSED. In fact, even in the absence of congestion, Part 3 can cause considerable variation in round trip times. Let's examine a pair of hosts talking to the same IMP over 9.6KB links. Packets must first traverse the Host1-IMP link then the Host2-IMP link. The ACKs must follow the reverse path. Without congestion, the time taken is mostly frame transmission times. When the TCP connection is first established, the packets will tend to be small (approx. 40 bytes) and the transmssion times small. The measured rtt will be very small (probably bounded by the resolution of the timer). If a sequence of full packets (approx. 1000 bytes) is now sent, the retransmission timeout will be based on the srtt derived from the small packets, but the transmission time will have increased by a FACTOR of 25! TCP will tend to retransmit before the frame has a chance to get to the other end. Depending on timer resolution and bounds, the first segment (hopefully only the first) can be retransmitted several times. Waiting until the packet has been transmitted by lower layers (not all implementations can do it) will help some for hosts directly connected to slow links, but consider a LAN-connected host going to a gateway which exits via a low speed link. This problem will persist until srtt is adjusted enough to allow sufficient time (some implementations ignore rtts when retransmitting, thus delaying updating srtt). Unfortunately, a burst of short packets can drive srtt back down very quickly (accumulating N samples using long packets takes much longer than using short packets). And retransmitting long segments is the worst thing to do when congestion is because of a low speed exit link. The retransmission timer is usually set to beta*srtt (within bounds), where beta (typically approx. 2) is supposed to accomodate any variance. But the variance can be much larger than typical betas. I propose that a possible solution is to accumulate a smoothed variance estimate which changes much more slowly than srtt: svar=gamma*svar+|(1-gamma)*(srtt-rtt)| (gamma >> alpha). The smoothed variance would then be used adjust the retransmission timer to accomodate the observed variance on the path. One could just boost the beta value to a much higher value, but that would be inefficient when packets are lost on a low variance path. I believe that congestion tends to build up quickly and dissipate slowly. Therefore it seems desirable for srtt to increase quickly but decrease more slowly. Maybe if rtt < srtt then alpha=large (0.9?) else if rtt > srtt then alpha=small (0.5?). Also, I wounder if it makes sense to have retransmission timers which are much less than IP Time-to-Live (some TCPs pass TTL values to IP). Of course TTL is really used more as a hop count than a real time value. My view of an ideal TCP would be one that could estimate average minimum delay, average variance and average THROUGHPUT. Segments would be metered out at the rate that the network appears to be able to accept them (rather than blasting a window's worth at a congested gateway) and the retransmission timer could account for observed delay and transmission time (using segment size and throughput). Also, some function of delay and throughput may be useful in dynamically adjusting segment size. Any comments? Art Berggreen Art@ACC.ARPA ------
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Thu, 7-May-87 16:47:17 EDT From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) To: comp.protocols.tcp-ip Subject: Re: question about FTP data channels
Phil-- You haven't answered your own question if you believe, as I do, that it's a bug for a Host to use different Internet Addresses during the same "conversation". cheers, map -------
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 7 May 1987 16:47:17 EDT From: Michael Padlipsky <PADLIPSKY@A.ISI.EDU> To: karn@FLASH.BELLCORE.COM (Phil R. Karn) Cc: tcp-ip@SRI-NIC.ARPA, tcp-ip-rebroadcast@SRI-NIC.ARPA Subject: Re: question about FTP data channels
Phil-- You haven't answered your own question if you believe, as I do, that it's a bug for a Host to use different Internet Addresses during the same "conversation". cheers, map -------
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Thu, 7-May-87 18:33:00 EDT From: SYSTEM@CRNLNS.BITNET To: comp.protocols.tcp-ip Subject: Re: Ethernet Terminal Concentrators
Thanks for the information about WIN/VX performance. My tests of the CMU/TEK TCP/IP package were using CMU's "shared DEUNA" code. DECnet and LAT were also using the same hardware. CMU's software uses DEC's XE driver, creating additional logical devices. Obviously, I'll have to try to do another test using a separate DEUNA. Selden
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 May 87 18:33 EDT From: <SYSTEM%CRNLNS.BITNET@wiscvm.wisc.edu> To: tcp-ip@sri-nic.arpa Subject: Re: Ethernet Terminal Concentrators
Thanks for the information about WIN/VX performance. My tests of the CMU/TEK TCP/IP package were using CMU's "shared DEUNA" code. DECnet and LAT were also using the same hardware. CMU's software uses DEC's XE driver, creating additional logical devices. Obviously, I'll have to try to do another test using a separate DEUNA. Selden
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Thu, 7-May-87 18:52:57 EDT From: ROODE@BIONET-20.ARPA (David Roode) To: comp.protocols.tcp-ip Subject: Re: Ethernet Terminal Concentrators
The numbers you quote are extremely similar to those sent by David Kashtan over a year ago concerning the affect of context switching on performance of Telnet service. Kashtan is the implementor of a package which includes IP and TCP and TELNET and which has now become available from SRI International. This package has been in existence for a very long time, and his previous message, if memory serves me, concerned some experiments he did with a non-Kernel implementation of the above protocols. The problem is that the CPU can be consumed by the context switching needed for character at a time I/O as common in Telnet. Kashtan's experience was that a single 9600 baud Telnet connection could consume nearly an entire 780. Again, this is subject to my recall. However, his implementation handles things very differently and runs in Kernel mode. As a result it is much more efficient. We have it here on MicroVaxes and it is the primary means for users to use the machine, i.e. there are no hardwire terminal ports to speak of, so everyone comes in via cisco boxes. We note no problems with the Telnet connections to the microvax consuming excess resources, although we typically only have 6-8 at a time of peak usage. -------
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Thu, 7-May-87 21:00:00 EDT From: RCLee@HI-MULTICS.ARPA.UUCP To: comp.protocols.tcp-ip Subject: Query: gateways, routers/bridges, and VMS
Honeywell is planning on replacing its end-host Multics connection
(HI-Multics.ARPA) with a DDN/Ethernet gateway.
The primary candidates for the gateway system are:
1. cisco Systems AGS-1A1E1M
2. CMC DRN-3200
While both look good to me, I am leaning towards the AGS due to the initial
price of the 1822L setup (cheaper), the ease of converting to DDN-X.25 at a
later date (cheaper, plug-and-play vs. unit exchange), and the expansion
capbility.
For connecting our remote Ethernets (aprox. 6), I am considering:
1. Bridge Communications GS/3-TCP router with conversion to the IB/3 IP
bridge when it gets released later this year.
2. cisco Systems AGS-1E3S2T1M TCP router
While initially I was leaning to cisco, Bridge is currently in the lead.
The main reasons are that all of the remote Ethernets are Bridge LANs and
Honeywell has an excellant working relationship with Bridge.
Now for the Questions (You knew there were going to be questions, didn't
you?):
1. For people who are gateway administrators, how much time do you spend
taking care of the gateway? 1/4 time? 1/2 time? Full time??!!!!!
2. Assuming that upgrade to DDN-X.25 wasn't an issue, which box would you
purchase? What other stand-alone 1822L/Ethernets gateways would you
consider?
3. Given the choice between a router and a bridge which would you choose?
To me, the protocol independence of the bridge offers a real selling point
since out LANs contain TCP-based hosts, XNS-based terminal servers, and
DECnet'ed VMS systems. However, I have seen messages on this list about
problems with both bridges and routers. Assuming that we don't mix
metaphors, i.e., connecting 2 Ethernet segments with both a bridge and a
router/gateway, can packet looping problems occur?
4. Does any one know of nameserver/domain software for VAX/VMS?
Conferencing systems that allow transactions via SMTP based mail?
--Randy Lee
rclee@HI-Multics.ARPA
...!umn-cs!hi-csc!rclee
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: Thu, 7-May-87 21:11:03 EDT From: melohn@SUN.COM.UUCP To: comp.protocols.tcp-ip Subject: Re: Ethernet Terminal Concentrators
Local Area Terminal is a DEC propritary protocol. Hypothetically, if you were to combine the I/O from several terminal sessions into a single message between each server and host pair, you might very well exceed the figures Charles is seeing with Cisco Terminal concentrators, espcially when multiple sessions are communicating with the same host. If you limited the frequency of how often you sent messages to each host to some value (like 80ms), and required the host to in most cases send a message only in reply to a message from the server, the amount of traffic would be further reduced.
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: Thu, 7-May-87 21:21:49 EDT From: karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP To: comp.protocols.tcp-ip Subject: Re: off RIP packet
Your friend at 26.12.0.122 has added you to his list of external routed gateways. This is obviously nonsensical as you don't share a net. I can't understand how this got your routing into a loop, as any routes derived from him should be rejected (that address isn't reachable as a next-hop gateway). Mike
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: Thu, 7-May-87 22:10:25 EDT From: leres@ucbarpa.Berkeley.EDU.UUCP To: comp.protocols.tcp-ip Subject: Re: Ethernet Terminal Concentrators
I'm not familiar with the cmu/tek vms tcp/ip. Does it use the Salkind epacket/elink code? The (low) performance you quote in your posting leads me to believe so. Salkind's code was the first to share the deuna with decnet. Basically, a process (elink) hangs reads on the deuna and on a raw internet socket. When a packet comes in off the wire, elink gets it and then writes it onto the raw socket. It goes through the internet code, comes out via the indriver, and arrives in the users buffer. An out bound packet goes the other way; from user process to internet kernel to elink process to deuna driver. At the time it was first implemented, elink was great; you could have decnet and internet on your machine without buying two ethernet interfaces. But obviously, having data pass through the elink process isn't very efficient. Decnet uses an (undocumented) internal interface to the ethernet driver called the alt start facility. This facility allows kernel use of the ethernet driver. I recently rewrote epacket for the Wollongong Group's WIN/VX product. Now, packets go directly from the ethernet driver to the internet code so things runs faster and uses less cpu time. If I login to a 9600 baud hardwired terminal on a 780 and telnet to a 750 and do "help /nopage * * *", the 780 is 95% idle and the 750 is 60% idle. On occasion, I have achieved 85 Kbytes/sec between the VMS 780 and a 4.3 Unix 780. I've heard that Kashtan rewrote epacket to use the internal "ffi" interface to the ethernet driver for SRI's Multinet product. I'd expect it to also be much faster than an elink process implementation. I don't sell or distribute these products. If you are interested in them, please contact TWG or SRI. Craig
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 7 May 87 18:30:29 GMT From: nbires!opus!atkins@ucbvax.Berkeley.EDU (Brian Atkins) To: tcp-ip@sri-nic.arpa Subject: NetBIOS over TCP/IP, Internetworking
I would like info on any solutions to the Internetworking problem with
NetBIOS over TCP/IP. I have RFC.100[12], but am looking for a simpler
solution, involving broadcast ("B") nodes only.
Thanks
Brian Atkins atkins@nbires.UUCP or atkins@nbires.NBI.COM
NBI Inc., P.O. Box 9001, Boulder CO 80301 (303) 938-2986
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: Thu, 7-May-87 22:53:00 EDT From: WANCHO@SIMTEL20.ARPA To: comp.protocols.tcp-ip Subject: off RIP packet
Chuck, The route daemon, routed, was experimentally turned on, eventually discovered to be a mistake, and since turned off. They were coming from an Ethernet host on the other side of an Ethernet-to-X.25 IP router connected to 26.12.0.122. The host, an AT&T 3B5, does indeed run AT&T SYS V Release 2.0.1 with the Wollongong TCP/IP. The reason you did not receive a direct reply is the reason that routed was turned on in the first place. It was thought that routed would solve the startup overhead of having to process route add commands for every gateway in the world. There obviously must be a better way - it's only because there's no definitive instructions that trial-and-error was used. If you know the correct way to solve the problem, please let me know, and I'll pass the word. --Frank
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 May 87 09:44:30 pdt From: imagen!apolling!geof@decwrl.DEC.COM (Geof Cooper) To: tcp-ip@sri-nic.ARPA Subject: Ringnets vs. Ethernets
From my (albeit quick) scanning of the messages about Suns on an Ethernet, it seems that accepted practise is to put 10-20 Sun's on a single ethernet and gateway from there. Larger numbers of diskless suns burden the network excessively. It is interesting to note that we at IMAGEN have about 50 diskless apollos (I lost count somewhere around 50) and 11 or 12 500MB disk servers. All these reside on a single 12 Mb/s token ring. We have seen the servers get overworked during the peak hours (yes, virginia, our WORKSTATIONS slow down a bit from 2-4 every afternoon) we haven't noticed the network getting congested. Oh yes, of the 50 apollos, most are 1.5 MB systems -- so they spend a LOT of time swapping. The merits of apollo and sun systems (and apollo's ringnet, which is far less reliable than our local Ethernet) notwithstanding, it is instructive to note that the theoretical justifications for choosing token contention over aloha contention seem to work in practise in this case. - Geof
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: Fri, 08 May 87 09:44:47 -0400 From: Mike Brescia <brescia@CCV.BBN.COM> To: WANCHO@SIMTEL20.ARPA Cc: Charles Hedrick <hedrick@TOPAZ.RUTGERS.EDU>, tcp-ip@SRI-NIC.ARPA, admin@HUACHUCA-EM.ARPA, brescia@CCV.BBN.COM Subject: starting up a system (was: off RIP packet)
the startup overhead of having to process route add
commands for every gateway in the world.
For a first cut, I thought that on your local net you could do a 'route add'
your own gateway as the default, and on milnet or arpanet, do a 'route add' of
your two assigned arpanet-milnet gateways (primary and secondary, as in DDN
mgt bull 23 or its successor).
You want more efficient routes? That's a second level issue.
Mike
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: 8 May 87 07:08 EDT From: ARPANETMGR @ DDN1.arpa To: tcp-ip @ sri-nic.arpa Cc: BSTeele @ bbn.com, FTardo @ bbn.com Subject: Arpanet Ops Center host line down temporarily
THE ARPANET OPS CENTER 800 # WILL BE DOWN A FEW HOURS SOMETIME ON SATURDAY
9 MAY (MOST LIKELY THE AFTERNOON). SINCE WE DO NOT KNOW THE EXACT
DOWN TIME WE RECOMMEND THE FOLLOWING PROCEDURE SHOULD YOU NEED TO CALL
ARPANET OPERATIONS:
FIRST CALL THE 800 492-4992 NUMBER. IF THERE IS NO ANSWER OR IT
IS CONTINUOUSLY BUSY --
CALL 617 497-3070.
THIS IS A TEMPORARY REQUIREMENT AND THE 800 NUMBER SHOULD BE BACK
IN SERVICE SUNDAY, 10 MAY.
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: Fri, 08 May 87 10:13:55 -0400 From: Mike Brescia <brescia@CCV.BBN.COM> To: Mike Karels <karels%okeeffe@UCBVAX.Berkeley.EDU> Cc: Charles Hedrick <hedrick@TOPAZ.RUTGERS.EDU>, tcp-ip@SRI-NIC.ARPA, brescia@CCV.BBN.COM Subject: Re: off RIP packet
>> Your friend at 26.12.0.122 ...
I have spoken on the telephone with the host administrator there. He is
appraised of the fact that he needs to redo the RIP configuration, and also
acquire EGP and properly configure it.
Mike
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 May 87 09:43:22 MDT From: Frank J. Wancho <WANCHO@SIMTEL20.ARPA> To: brescia@CCV.BBN.COM Cc: hedrick@TOPAZ.RUTGERS.EDU, tcp-ip@SRI-NIC.ARPA, admin@HUACHUCA-EM.ARPA, WANCHO@SIMTEL20.ARPA Subject: Re: starting up a system (was: off RIP packet)
Mike, I should clarify the nature of the Ethernet-to-PS connection as a "port extender," which, on a Class A PS, interprets the otherwise unused third octet as host addresses on the Ethernet. In other words, hosts on the Ethernet appear to be directly connected hosts. I have already done the 'route add' commands for the two assigned arpanet-milnet gateways with no change in connectability. We still see 'network unreachable' in trying to connect to hosts on any other network. This implies that ICMP is not implemented in the code we have. That is an issue we will take up with the vendors involved and drop any further discussion here. Our thanks to all who replied. --Frank -------
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 May 87 11:34 PDT From: Kevin Carosso <KVC@ENGVAX.SCG.HAC.COM> To: tcp-ip@sri-nic.ARPA Subject: Re: Ethernet Terminal Concentrators
> Thanks for the information about WIN/VX performance.
>
> My tests of the CMU/TEK TCP/IP package were using CMU's "shared DEUNA"
> code. DECnet and LAT were also using the same hardware.
> CMU's software uses DEC's XE driver, creating additional logical devices.
> Obviously, I'll have to try to do another test using a separate DEUNA.
No, no, no! The performance problem with the CMU code is NOT due to the
existence of some mythical "shared DEUNA code". Under VMS the
DEUNA/DELUA/DEQNA/DEBNT/etc drivers always present the ethernet controller as a
shared device. I wish people would quit refering to the "shared DEUNA" as if it
were something special. I also wish other people would quit selling, at
additional cost mind you, the "option" of sharing your DEUNA! If (under
VAX/VMS using a DEC supported ethernet device) it ain't shared then it ain't
done right! Please note, this does NOT mean that if it IS shared it IS
done right. The Wollongong "shared DEUNA option" as outlined in the
Product Profile for part number A-204-071 is a prime example of that.
DECnet and LAT both use the same "shared DEUNA" and exhibit perfectly
acceptable performance.
The performance problems we see with the CMU code are due to the fact that the
code runs in USER mode as an ACP (separate process). In addition, the TELNET
server runs in USER mode as a separate process. There is a lot of context
switching and buffer copying going on. Similarly, the Wollongong shared DEUNA
option uses a separate process between the network code and the DEUNA device,
introducing context switches and buffer copies.
If the Wollongong code were to use the FFI or alternate start IO entry point to
the DEUNA driver directly from the kernel, they could share the controller and
buy back the performance edge that their kernel code has. From the followup
note to TCP-IP it sounds like they are indeed doing something like this.
/Kevin Carosso kvc@engvax.scg.hac.com
Hughes Aircraft Co. kvc%engvax@oberon.usc.edu
ps. Myself and Ned Freed wrote the original DEUNA and DEQNA module for
the Tektronix TCP/IP which CMU picked up and reworked.
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 8 May 1987 09:17-EDT From: CLYNN@G.BBN.COM To: karn@FLASH.BELLCORE.COM Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: question about FTP data channels
Phil, The server FTP is broken; it is required to use as its address the address which the client used when establishing the control connection. Please report it to the FTP vendor so that they can fix their code. Charlie
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: Fri, 8-May-87 10:49:00 EDT From: mishkin@apollo.uucp (Nathaniel Mishkin) To: comp.protocols.tcp-ip Subject: Re: Ethernet Suffering
I found all this discussion about loaded ethernets pretty interesting.
Having used Apollos (both in and out of Apollo Computer Inc.) for the
last ~5 years, I've become pretty familiar with the vices and virtues
(much of the former) of token ring networks and often wondered why we
wouldn't just be better off with ethernet. I think the recent discussion
in this group highlights some of the virtues of token ring networks.
I was fairly astonished to hear read one basically can run no more than
(based on the various estimates) 8-15 diskless workstations (of some
manufacture) on a single ether. I shudder to think of the cost (in money
and performance) of *requiring* routers/bridges and internetwork topology
for a relative small "work group". You just don't have these problems
in a token ring. Token rings guarantee fair access to the medium and
as a result can run successfully with consistently higher average loads.
And forget diskless workstations for a minute. How about doing file system
backups over the net? There's a fine bit of load; and it's not bursty
like diskless workstations. In our multi-hundreds of gigabyte environment,
backups (like love) are forever.
I also thought the comment about how improved caching would help matters
was interesting. Of course, proper caching requires correct cache
validation to ensure that you're reading valid data. Not all distributed
file systems implement such correctness guarantees. For example, Apollo's
distributed file system does, but NFS doesn't.
--
-- Nat Mishkin
Apollo Computer Inc.
Chelmsford, MA
{wanginst,yale,mit-eddie}!apollo!mishkin
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: Fri, 8-May-87 12:35:05 EDT From: lamaster@ames.UUCP (Hugh LaMaster) To: comp.protocols.tcp-ip Subject: Re: Ethernet Terminal Concentrators
In article ... SYSTEM@CRNLNS.BITNET writes: > >The problem that we've encountered is the high >CPU overhead used by at least one TELNET implementation under VMS. >The following is a report of a test done using CMU/TEK TCP/IP : >CMU/TEK TCP/IP software uses an excessive amount of cpu resources >2 VAX-11/750s (LNS53 and CLE750) with FPA and 5 Megabytes of memory, >running VMS 4.4 and connected with DEUNA Ethernet interfaces. >The transfer used 100% of the cpu on (remote) CLE750 > ==== >(20% kernel, 80% user, <5% interrupt) > >User mode programs on on CLE750 were the TELNET server using about 50%, >IP_ACP using about 15%, and TYPE using about 15%. One part of the results surprised me, based on my experiments. I have performed essentially the same experiments, using Wollongong TCP/IP on VMS. a terminal uses about 5-6% in user state. However, during the same period, total system usage (user + interrupt + kernel) was about 15%. This was true with both telnet and a direct wired terminal. Two points: 1) Wollongong TCP/IP is clearly more efficient than the TCP/IP you used; and 2) I saw higher overhead from direct wired terminals than you did (I am wondering why right now :-) ). Anyway, I was concerned about telnet overhead myself, but found no observable difference between network and direct wired. This surprised me, I admit; Wollongong has improved a great deal in the last releases. An interesting part to me was discovering just how expensive terminal I/O is on VMS. 7 9600 baud terminals at full output saturated a 785... I think it is definitely a question which should be addressed more carefully by the terminal server vendors. Some implementations work fine, others seem to be a problem. Most of the vendors don't seem to have looked at this as carefully as I would have expected.
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 May 87 13:32:41 EDT From: hedrick@topaz.rutgers.edu (Charles Hedrick) To: RCLee@hi-multics.arpa Cc: tcp-ip@sri-nic.arpa Subject: Re: Query: gateways, routers/bridges, and VMS
For an Arpanet gateway and a single gateway connecting several networks, I would think you would spend a few days setting each of them up, a few day every few weeks changing something, and a few hours a week looking into problems. This will make you the de facto network administration, since any time anyone has a network problem, they will claim it is something your gateway did. So it depends upon the size and complexity of your network. But I'd bet that it would be full time for somewhere between a week and a month, and then 1/4 time. But the 1/4 time will include lots of firefighting, which will require you to drop everything and fix a critical problem, and will always happen at the worst possible time for you.
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: 8 May 87 17:00:00 EST From: "NRL::HERMAN" <herman%nrl.decnet@nrl.arpa> To: "tcp-ip" <tcp-ip@sri-nic.arpa> Subject: Binary file transfer
Hello out there in netland, I want to send a binary file over the net, however the person to whom I want to send the file does not have access to FTP. Is it possible to do it? I access arpanet using MAILER in the VMS mail utility, and the destination node is @relay.cs.net. Thank in advance for any information. Charles Herman ------
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: Fri, 8-May-87 18:19:15 EDT From: mark@mimsy.UUCP (Mark Weiser) To: comp.protocols.tcp-ip Subject: Re: Ethernet Suffering
In article <34bd5209.c366@apollo.uucp> mishkin@apollo.UUCP (Nathaniel Mishkin) writes: >...I think the recent discussion >in this group highlights some of the virtues of token ring networks. >I was fairly astonished to hear read one basically can run no more than >(based on the various estimates) 8-15 diskless workstations (of some >manufacture) on a single ether. I think this is a misinterpretation of the comments. I have seen Apollo networks exhibiting extremely poor performance when too many diskless nodes were accessing a single server. (Too many did not seem to be all that many--I saw this at the Brown demonstration classroom, when all the diskless clients were trying to start at once.) I think that the question is: what does it mean to 'run no more than...'. Sure you can run more than 8-15, but the performance will look worse. If you are used to a local disk, then you can 'feel' the decrement with more than 8-15 diskless workstations on the ethernet. On the other hand, if you are willing to accept low-performance transients (as the Brown folks evidently were on their Apollos during startup), then you can do more. Another angle: there are lots of reasons why performance could be different between these two systems. It is premature to point the finger at the 0/1 networking levels without more information. -mark -- Spoken: Mark Weiser ARPA: mark@mimsy.umd.edu Phone: +1-301-454-7817 After May 15, 1987: weiser@parcvax.xerox.com
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: Fri, 08 May 87 15:28:42 +0100 From: Jon Crowcroft <jon@Cs.Ucl.AC.UK> To: tcp-ip@sri-nic.arpa Subject: tcp on OSx 3.1
We have a Pyramid 98X running release 3.1 OSx (4.2BSD + Sys V derived). TCP between it and other machines (Sun 2s, 3s, PDP 11/44s vaxes microvaxes, lrts, HLH Orion, PCs running PC/IP etc etc) works fineish over a single Ethernet. When we interpose a Cisco IP Router between two segments of our ethernet (subnetting), the TCP breaks. It breaks spectacularly in that any bulk transfers (ftp/rcp/etc) lose connections after a few kbytes transfer. Note that the Cisco has 3Com ethernet interfaces, and does not cope well with back to back packets, especially large ones. It forwards packets as it can receive them, but the later ones in a burst get dropped. Suns et al (mostly standard Berkeley TCPs) all work in this situation, with a certain amount of window juggling and retransmissions. The Pyramid TCP seems to retransmit everything whenever a packet is dropped, and also seems to advertise a receive window of 80kbytes unvaryingly. Anyone seen similar behaviour, and got any fixes or suggestions?
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Fri, 8-May-87 22:13:00 EDT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: question about FTP data channels
Phil, don't you have to accommodate the case of third party transfers, so that the control address is distinct from sender and receiver of the file transfer? If that's so, then you can't very well bind to the source address of the control process. Vint
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Sat, 9-May-87 08:27:17 EDT From: kluger@roundhouse.UUCP (Larry Kluger Sun Europe) To: comp.protocols.tcp-ip Subject: Re: Dec's LAT protocol
Speaking of LAT, has anyone seen a spec for it? (I'm only interested in public documentation. A dec part number, article reference/citation, etc.) I've heard conflicting rumours that LAT is and is not a secret. Thanks, Larry Kluger Sun Microsystems Europe ps. There is sunshine in England today! This is news!!
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: Sun, 10-May-87 10:56:22 EDT From: merlin@hqda-ai.UUCP (David S. Hayes) To: comp.mail.misc,comp.protocols.tcp-ip Subject: Dial-up TCP/IP (was interactive SMTP over phone lines)
In article <16608@amdcad.AMD.COM>, bandy@amdcad.AMD.COM (Andy Beals) writes:
> I don't know about you, but the last time I dialed-up a
> computer, I got line-noise. Interactive smtp is nice but you
> need to have an error-free datastream between them. So, anyone
> for writing a point-to-point dialup tcp/ip?
This discussion seems headed to the general possibility of
doing TCP/IP over a dialup phone line, so I'm moving it to
comp.protocols.tcp.
Ideally, we'd like to be able to write a daemon that can
listen for non-local IP requests, check against a list of dial-up
machines and their addresses, dial the phone, and then act as a
pass-through. All this should be done without any kernel
modifications.
I don't know if this can be done with current 4.x BSD
kernels. Used to be that all BSD sites had source, but with the
rise of the workstation vendors, that's not true anymore.
Perhaps raw sockets would provide a means to do this, but
it's been quite a while since I did anything with raw sockets.
Anyone else have any ideas?
--
David S. Hayes, The Merlin of Avalon PhoneNet: (202) 694-6900
UUCP: *!seismo!sundc!hqda-ai!merlin ARPA: merlin%hqda-ai.uucp@brl.arpa
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Sun, 10-May-87 18:36:49 EDT From: connery@bnrmtv.UUCP (Glenn Connery) To: comp.protocols.tcp-ip Subject: Re: Ethernet Suffering
In article <34bd5209.c366@apollo.uucp>, mishkin@apollo.uucp (Nathaniel Mishkin) writes:
> I was fairly astonished to hear read one basically can run no more than
> (based on the various estimates) 8-15 diskless workstations (of some
> manufacture) on a single ether... You just don't have these problems
> in a token ring...
Since you are not comparing equivalent systems this kind of interpretation
of the results seems rather unwarranted. The discussion to date has
pointed out that the Suns are doing paging of the virtual memory over the
Ethernet. Depending upon the way things are set up this could be a huge
load for the network to handle, regardless of the efficiency of the
access protocol.
--
Glenn Connery, Bell Northern Research, Mountain View, CA
{hplabs,amdahl,3comvax}!bnrmtv!connery
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Mon, 11-May-87 10:00:00 EDT From: mishkin@apollo.uucp (Nathaniel Mishkin) To: comp.protocols.tcp-ip Subject: Re: Ethernet Suffering
In article <6603@mimsy.UUCP> mark@mimsy.UUCP (Mark Weiser) writes:
>In article <34bd5209.c366@apollo.uucp> mishkin@apollo.UUCP (Nathaniel Mishkin) writes:
>>...I think the recent discussion
>>in this group highlights some of the virtues of token ring networks.
>>I was fairly astonished to hear read one basically can run no more than
>>(based on the various estimates) 8-15 diskless workstations (of some
>>manufacture) on a single ether.
>
>I think this is a misinterpretation of the comments. I have seen
>Apollo networks exhibiting extremely poor performance when too many
>diskless nodes were accessing a single server.
I think there's some confusion here: *I* was not talking about the number
of diskless workstations that could be booted off a single server. Maybe
other people were. It seemed that people were talking about the number
of diskless workstations that could be on a single local network (e.g.
ether or ring).
Further, let me make it clear that when I said I gave the range "8-15"
I was merely quoting the numbers that had appeared in the earlier articles
to which I was following up. (I.e. I should not be considered an authority
on the performance characteristics of other manufacturer's workstations :)
Unless I was misreading, these quotes were from articles that seemed
to be discussing the number of diskless workstations per ether, not per
disked server. I'll leave it to the real authorities to clear things up.
>Another angle: there are lots of reasons why performance could be different
>between these two systems. It is premature to point the finger at the
>0/1 networking levels without more information.
Fair enough. I was just trying to provide some more information that I thought
was relevant.
--
-- Nat Mishkin
Apollo Computer Inc.
Chelmsford, MA
{wanginst,yale,mit-eddie}!apollo!mishkin
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Mon, 11-May-87 10:35:00 EDT From: mishkin@apollo.uucp (Nathaniel Mishkin) To: comp.protocols.tcp-ip Subject: Re: Ethernet Suffering
In an earlier posting of mine, I unjustly sullied the capabilities of
the NFS protocol in the area of caching. My cursory reading the the
NFS Protocol Spec (which doesn't explicitly discuss caching issues) failed
to catch the frequent "attributes" return parameters that one is, I take
it, to use in cache management if one is to have an efficient NFS
implementation.
Open mouth; extract foot.
--
-- Nat Mishkin
Apollo Computer Inc.
Chelmsford, MA
{wanginst,yale,mit-eddie}!apollo!mishkin
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: Mon, 11-May-87 11:51:45 EDT From: kent@DECWRL.DEC.COM To: comp.protocols.tcp-ip Subject: Re: Dial-up TCP/IP (was interactive SMTP over phone lines)
This topic seems to come up every year or so. I have some old messages (from 83) where a few of us discussed this topic. The raw sockets sort of approach seems good, as far as it goes. The real problem seems to be that the IP protocol family (especially TCP) believe in short packet lifetimes (30-60 seconds for TCP open timeout, ~255 seconds total packet lifetime), and this is hard to achieve in a dialnet environment, where it can take 30 seconds to convince a dialer to dial a number and connect the call, much less get logged in, switch the dial port to be an IP link, etc. On top of that, protocols like SMTP count on being able to reach the destination host directly; there's no concept of uucp-ish store and forward in the protocols. This makes opens take even longer; several hosts in succession may have to dial and open connections, depending on the diameter of the net. There are even desirable configurations where it is impossible to have everyone connected at the same time -- say neither hosts A nor B have dialers, but are both periodically polled by C. A and B can never be connected at the same time, thus can't exchange IP packets. That seems to be where the idea of dialup is incompatible with the IP networking model... Cheers, chris
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: Mon, 11-May-87 12:25:26 EDT From: jas@MONK.PROTEON.COM (John A. Shriver) To: comp.protocols.tcp-ip Subject: Ethernet Suffering
We are looking at several effects here. One is server saturation proper-how fast its disks and protocols can run. The next is saturation of the server interface. The third is saturation of the LAN itself. All three are sensitive to the LAN technology. Server protocol performance can be effected relatively easily by LAN packet size. If you've got big packets (4K instead of 1.5K), you'll take less interrupts and context switches. Saturation of the server interface is to a great degree a matter of good design. Having enough buffering, a clean programming interface, and an ability to pipeline can definitely help receive/transmit more data. However, having any level of data link flow or congestion control can really help. Most CSMA networks have no way to know if a packet was really received at the server, or was dropped for lack of a buffer. Some CSMA networks (DEC's CI) do this, and it helps a lot. (Ethernet does not.) All of the Token-Ring networks (IBM's, our ProNET, ANSI's FDDI standard) have this, in the "frame copied" bit that comes back around from the recipient. This makes the possibility of lost packets due to server congestion dramatically lower, which really speeds things up. The data link can implement flow control & retransmission much faster than the transport code. The LAN itself can have dramatically different total capacity, which matters when you want 3 servers on one LAN, not just one. On 10 megabit networks, you can get more total data through, with less delay, on a Token-Ring than a CSMA/CD network. While vendors will disagree on where CSMA/CD congests terminally (somewhere between 4 and 7 megabits/second), it is true that Token-Ring can really deliver all 10 megabits/second. Moreover, at speeds beyond 10 megabits/second, CSMA/CD does not scale, and you almost have to go Token-Ring. (You can go CSMA/CA, but it can degenerate into a Token-Bus.) The FDDI standard is a Token-Ring, as is the ProNET-80 product.
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Mon, 11-May-87 12:38:00 EDT From: CERF@A.ISI.EDU.UUCP To: comp.protocols.tcp-ip Subject: Re: Dial-up TCP/IP (was interactive SMTP over phone lines)
Chris, How about running full TCP/IP on the dial-up link to deal with the problem of store/forward - this limits the application of IP to pt-pt applications such as mail, where the store/forward is outside the context of the initial TCP connection. Vint
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 11 May 1987 12:38-EDT From: CERF@A.ISI.EDU To: kent@SONORA.DEC.COM Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Dial-up TCP/IP (was interactive SMTP over phone lines)
Chris, How about running full TCP/IP on the dial-up link to deal with the problem of store/forward - this limits the application of IP to pt-pt applications such as mail, where the store/forward is outside the context of the initial TCP connection. Vint
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Mon, 11-May-87 13:19:26 EDT From: kent@DECWRL.DEC.COM To: comp.protocols.tcp-ip Subject: Re: Dial-up TCP/IP (was interactive SMTP over phone lines)
Vint, That was the plan -- to run all the protocols intact. The original impetus for the idea was to punt explicit store-and-forward mail systems (like uucp). I'm not in favor of introducing any new mechanisms into the Internet that require explicit routing by the user. We already have people doing dial-up IP from home machines, and Dave Mills has had fuzzies doing it for much longer than that (I booted my first fuzzball long distance at 1200 baud in 1983, and it was old hat then). The problem seems to be making multi-hop configurations work with existing TCP/SMTP implementations. chris
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: Mon, 11-May-87 13:22:19 EDT From: minshall@OPAL.BERKELEY.EDU To: comp.protocols.tcp-ip Subject: Re: Dial-up TCP/IP (was interactive SMTP over phone lines)
How I would do TCP/IP from a micro over a phone line:
1. The user dials up their favorite IP host (TIP?).
2. The user logs in.
3. The user invokes, simultaneously on both sides, programs
which place a remote procedure call interface over the
wire, with reliability. The program on the IP host is,
basically, just a user application.
4. Then, the remote procedure call interface "gives" the
user programs on his micro, the ability to access the
hosts standard TCP/IP services.
Ttalking to a 4.2 system, if after establishing the dial-up
logon, I have a program which says:
{
...
s = socket(....);
if (s == -1) {
...
}
if (connect(s, ...) == -1) {
...
}
if (recv(s, ...) == -1) {
...
}
}
all of the calls "socket", "connect", "recv", etc., would be performed via
remote procedure call to the IP host.
(Better, possibly, would be to implement a standard set of TCP-over-dial
remote calls (like LU6.2 verbs) that everyone would recognize once
the system dependent call setup/login/invocation was performed.)
Note that in this way, we get out of having to assign a new IP
address to the client machine, and the user gets to move his/her
TCP/whatever programs down to his/her micro.
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: Mon, 11-May-87 13:29:00 EDT From: CERF@A.ISI.EDU.UUCP To: comp.protocols.tcp-ip Subject: Re: Dial-up TCP/IP (was interactive SMTP over phone lines)
Chris, If TCP is configured to be pretty persistent, and if there is only the one dial-up, low speed, circuit switched hop, I would think one can get the IP to work - assuming you can avoid dial-up for each packet! On the other hand, to introduce dial-up links virtually anywhere in the topology of the Internet, and low speed, to boot, without a reliable link protocol [forcing recovery to be via TCP] seems pretty hard to achieve. Vint
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: 11 May 1987 13:29-EDT From: CERF@A.ISI.EDU To: kent@SONORA.DEC.COM Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Dial-up TCP/IP (was interactive SMTP over phone lines)
Chris, If TCP is configured to be pretty persistent, and if there is only the one dial-up, low speed, circuit switched hop, I would think one can get the IP to work - assuming you can avoid dial-up for each packet! On the other hand, to introduce dial-up links virtually anywhere in the topology of the Internet, and low speed, to boot, without a reliable link protocol [forcing recovery to be via TCP] seems pretty hard to achieve. Vint
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: Mon, 11-May-87 13:36:54 EDT From: elvy%mbcrr@HARVARD.HARVARD.EDU.UUCP To: comp.protocols.tcp-ip Subject: dialup tcp
We have had TCP/IP running over telephone lines for some time, now, but it doesn't exactly conform to your specs. A server runs on each end of the telephone line, alternately (randomly) waiting for a call or attempting to make one. Once a connection is established, another process is run. When that process finishes, or when the connection is lost, the server hangs up the phone and attempts to re-establish the connection. As the "process", we use a program that keeps the line open (the server sets stdin and stdout to be the telephone line before execing the new process) and keeps it in SERIAL TCP line discipline (see kernel mods I sent to this mailing list in January 1984). In addition, we ifconfig the serial interface and route packets over it. Crude in concept, perhaps, but we have had a reliable Internet connection running more-or-less all the time for the past year over a distance that precludes normal cable connections and for a fraction of the cost of leased lines. Marc (elvy@mbcrr.harvard.edu)
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 May 87 13:36:54 EDT From: elvy%mbcrr@harvard.harvard.edu (Marc Elvy) To: "tcp-ip@sri-nic.arpa"@harvard.harvard.edu Subject: dialup tcp
We have had TCP/IP running over telephone lines for some time, now, but it doesn't exactly conform to your specs. A server runs on each end of the telephone line, alternately (randomly) waiting for a call or attempting to make one. Once a connection is established, another process is run. When that process finishes, or when the connection is lost, the server hangs up the phone and attempts to re-establish the connection. As the "process", we use a program that keeps the line open (the server sets stdin and stdout to be the telephone line before execing the new process) and keeps it in SERIAL TCP line discipline (see kernel mods I sent to this mailing list in January 1984). In addition, we ifconfig the serial interface and route packets over it. Crude in concept, perhaps, but we have had a reliable Internet connection running more-or-less all the time for the past year over a distance that precludes normal cable connections and for a fraction of the cost of leased lines. Marc (elvy@mbcrr.harvard.edu)
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: Mon, 11-May-87 15:11:00 EDT From: mishkin@apollo.UUCP To: comp.protocols.tcp-ip Subject: Re: Ethernet Suffering
[[This is a reposting of my response to Mark Weiser's article. This
one is slightly different from my earlier one. If I spend any more time
trying to figure out how to (successfully) cancel a previously posted
article, I think I'll go insane. Sorry for the noise. --mishkin]]
In article <6603@mimsy.UUCP> mark@mimsy.UUCP (Mark Weiser) writes:
>I think this is a misinterpretation of the comments. I have seen
>Apollo networks exhibiting extremely poor performance when too many
>diskless nodes were accessing a single server.
I think there's some confusion here. *I* was talking about the number
of diskless workstations per ethernet, not per server. I thought that's
what other people were talking about too.
Further, I want to make clarification: When I referred to 8-15 as being
the maximum number of diskless workstations (per ethernet), I was *merely*
quoting the numbers that appeared in the articles to which I was following
up. (I.e. I don't claim to be an expert on the performance characteristics
of other manufacturers' equipment.) I'll let the real experts clear things
up.
>Another angle: there are lots of reasons why performance could be different
>between these two systems. It is premature to point the finger at the
>0/1 networking levels without more information.
Climbing further out of the hole which I seem to have been digging myself
into: I agree with you. I was not trying to make a definitive comparison
between rings and ethers. I was simply trying to add some more information
to the discussion. A number of people here (at Apollo) have said to
me "Come on, this really can't be an ethernet saturation problem." Others
have extolled ring networks in even other ways that I can barely
understand.
Finally, before I shrink away, I feel obliged to point out that lest
anyone get the wrong impression, Apollo believes that both ring and ether
networks are fine ideas. These days, one can buy Apollo's DN3000s with
either or both of a ring or ethernet controller and all your Apollo
workstations can communicate (and share files) over complex
ring/ether/whatever internetwork topologies.
--
-- Nat Mishkin
Apollo Computer Inc.
Chelmsford, MA
{wanginst,yale,mit-eddie}!apollo!mishkin
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: 11 MAY 87 20:00-PDT From: Iglesias%UCIVMSA.BITNET@wiscvm.wisc.edu To: TCP-IP@SRI-NIC.ARPA Subject: Wollongong TCP/IP and subnets
Received: from ORION by UCICP6 with PMDFs; 11 May 1987 19:49:16 Received: from localhost by orion.uci.edu id a016906; 11 May 87 19:46 PDT Date: Mon, 11 May 87 19:46:43 -0700 From: Mike Iglesias <iglesias@orion.uci.edu> Does anyone know if Wollongong's TCP/IP will support a subnet mask of something other than 8 bits. It appears to be a fixed mask from reading the documentatin. Also, is there any way to set the broadcast address? Thanks, Mike Iglesias University of California, Irvine
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: Mon, 11-May-87 19:50:00 EDT From: dplatt@teknowledge-vaxc.ARPA (Dave Platt) To: comp.unix.wizards,comp.protocols.tcp-ip Subject: IP fragmentation, and how to avoid it
I've run into some problems on a Sun 3/52 workstation running SunOS
3.2 that I've been told may involve IP packet fragmentation. The
primary symptom is that SMTP mail deliveries "hang up" and abort with
a read timeout.
Background: my Sun is sitting on a 10 Mbit Ethernet with the default
ifconfig for the Ethernet board; the MTU for the Ethernet interface
is 1500 bytes. The system is configured so that packets destined for
IP addresses not on our net are sent to our Vax 8650 (Ultrix 1.2),
which ipforwards them to the Internet TIP. The MTU for the Vax's
"imp0" interface is 1006 bytes.
Problem: if a process on the Sun establishes a TCP connection with a
peer running on a host somewhere on the Internet (e.g. an SMTP
server), and then sends a large burst of data, the Sun will typically
queue up about 4k of data in the TCP buffers at one time. This
apparently results in the sending of an IP packet that approaches the
Sun's 1500-byte MTU; when the packet passes through the Vax on its way
to the IMP, it is apparently fragmented. Some system or gateway seems
to drop the fragmented IP packet on the floor. The Sun's TCP never
receives an acknowledgement for the TCP segment, retries the
transmission periodically, and eventually aborts the connection.
The problem typically occurs in the later stages of an SMTP session.
The Sun's SMTP mailer is able to connect with its peer on another
Internet host, go through the "MAIL FROM" and "RCPT TO" steps, and
receive permission to send the message body. If the message is short
(< 1k bytes), everything works fine; if it's too long, then the
timeout occurs.
This problem appears to occur only when the host I'm trying to connect
with lies on a local-area net... and not all LANs are affected. I've
been told that certain gateways are incapable of reassembling
fragmented IP packets; other gateways seem to work just fine.
Question for the gurus: is there any way to reconfigure my Sun's le0
interface so that its MTU doesn't exceed that of the 8650? If so, how
do I do it? Or, is there a better solution to the problem? Or,
finally, have I totally misunderstood the problem?
advTHANKSance,
Dave Platt
Internet: dplatt@teknowledge-vaxc.arpa
Usenet: {hplabs|sun|ucbvax|seismo|uw-beaver|decwrl}!teknowledge-vaxc.arpa!dplatt
Voice: (415) 424-0500
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: Tue, 12-May-87 00:16:00 EDT From: WANCHO@SIMTEL20.ARPA.UUCP To: comp.protocols.tcp-ip Subject: route add (was RIP)
Thanks to all who responded, and to Mike Muuss with the "correct" answer: to insert the two lines for the default gateways (nominally the "mailbridge homing" gateway hosts) with the destination field of "0". This was NOT mentioned in *any* documentation we have. This class of missing information is exactly the sort of thing I would like to see published in an online document available to any newly ordained system administrator and network liaison. Let's call it the Internet Systems Administrator's Handbook: a collection of hints, tips, and common sense security items (yours and the network community) for operating in the Internet environment. If such a document existed, we would have known not to run routed and *why*. If you already have such a document in your local community, or have material to submit toward the compilation of such a document, maybe the NIC would be interested in collecting and organizing it... --Frank
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: Tue, 12-May-87 11:10:33 EDT From: dms@HERMES.AI.MIT.EDU (David M. Siegel) To: comp.protocols.tcp-ip Subject: Dial-up TCP/IP (was interactive SMTP over phone lines)
Speaking of dial-up IP... I am looking into hooking up a home Sun-3 to IP via a modem. I was planning on using Serial Line IP (slip) for this purpose, but came up with a few problems: 1) The SLIP package doesn't support logging in to the IP connection, so anyone could dial up to the modem and connect to the network. 2) The SLIP host that's on the Ethernet end needs to know the IP address of the dialup host, so if different hosts can dialup to the IP connection, something must be done to handshake down the dialup host's Ethernet address. Question: has anyone done something like this, and is SLIP the right way to go? -Dave
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: Tue, 12-May-87 13:40:51 EDT From: minshall@OPAL.BERKELEY.EDU To: comp.protocols.tcp-ip Subject: Re: Dial-up TCP/IP (was interactive SMTP over phone lines)
Chris, Yes, there are two issues here. Circuit-switched IP is one. The other is, for me, how does one extend IP service to a large number of micros, many of which are sitting in someone's home, and connected via a dial-up phone line. My bias is that these do not need to have IP addresses assigned, and so can piggy-back off some existing host. Still, I think these machines need various TCP/IP *client* services (FTP, telnet, SMTP maybe), and I think the remote procedure call is valuable there. Yes, it needs a reliable data link layer, flow control, in-sequence delivery, etc. The user sitting at home would like to move files back and forth between the home system and hosts on the IP network, share file systems with other hosts, login over the network, etc. The RPC mechanism seems, to me, an interesting way of accomplishing that. Greg Minshall
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: Tue, 12-May-87 16:54:27 EDT From: minshall@OPAL.BERKELEY.EDU To: comp.protocols.tcp-ip Subject: Re: Dial-up TCP/IP (was interactive SMTP over phone lines)
Chris, Currently, a user logged in to one of our IP hosts can now run any/all of the client protocols they would like. When they do this, they run the protocol using the IP host's CPU cycles, and things they do that reference files (ftp, "screen capture" on telnet) they reference files located on the IP host system. What I would like is for any user with an account on any of our IP hosts to be able to dial in (from home), or otherwise connect, and run those same clients from their micro (thus affecting the files in the micro, and using, mostly, CPU cycles from the micro). One of the advantages here is that the user need not submit a "request for an IP address" form to the local administration. Nor do they need to know what IP address they are talking from. I am the first to admit that the RPC mechanism solves only the problem I am posing. Still, I think it is an interesting problem. As to your point about validation schemes, I tend to differ. I agree that the .rhosts scheme has limited usability (and can be something of a security hole). However, I think that the most interesting schemes will be those relying on authentication, keys, etc. (and NOT on knowledge of the remote host name). Again, my purpose is to allow micros to become clients. This is also my bias. Not to prompt any heated discussion, but I am dubious of the desirability of running SMTP servers on large numbers of micros. Here I think the POP-like protocols are more interesting. In those (relatively fewer) cases where it is necessary to run a machine with servers, then a separate IP address (and separate protocols) would be the way to go. I should make clear that I am not even seriously proposing any work in this area at this time. It is just an idea I've been kicking around for a while, and the recent discussion was enough to finally prod me into airing it a bit. Greg
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: Tue, 12-May-87 17:16:34 EDT From: kent@DECWRL.DEC.COM To: comp.protocols.tcp-ip Subject: Re: Dial-up TCP/IP (was interactive SMTP over phone lines)
Greg, Every time this issue comes up, I wonder why people don't want to assign addresses to micros. Is it just a problem of scale? I realize that most of the micros won't be hooked up at the same time. But, if you're going to have server SMTP service on the micro, that probably means that each micro needs a unique name. If you don't assign it a permanent number, then you have a real headache at startup, interacting with the nameserver database, etc. If you're just talking about having client services on the micros, then you can get away with random names/numbers. But home micros are getting powerful enough that people might want to have server SMTP sitting there. Another authorization problem arises for home micros that want to be remote file system clients. It seems very difficult to use the flexible protection/authentication mechanisms that are appearing if you don't know exactly which host is the client -- the 4.2 .rhosts mechanism breaks down pretty quickly. The contents of .rhosts either becomes all possible dialup hostnames, or is essentially useless. chris
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: Tue, 12-May-87 17:18:16 EDT From: ROODE@BIONET-20.ARPA (David Roode) To: comp.protocols.tcp-ip Subject: Re: dialup tcp
There must be something else to your story, or else the tariffs differ greatly from what I am used to. In California, a switched telephone line costs ~$15 per month with the FCC surcharge, but keeping it connected 24 hours a day would cost in usage charges an additional $300 per month. Leased lines can be had for $40 per month over distances up to 5 miles or so at least. Leased lines are 4-wire circuits and as a result I'd say the modems tend to be slightly more economical than those suitable for the dial network. What makes your situation different? -------
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: Tue, 12-May-87 17:26:29 EDT From: kent@DECWRL.DEC.COM To: comp.protocols.tcp-ip Subject: Re: Dial-up TCP/IP (was interactive SMTP over phone lines)
The question isn't really how to do TCP on a phone line to allow a micro in, but rather how to build something like a circuit-switched IP network. As evidenced by the mail on the list, lots of people have had user-initiated dialup IP for some time. Most implementations just run IP over the wire (with something like SLIP or compressed SLIP as the data link layer), with acceptable performance. The remote procedure interface is interesting, but you need to build some sort of reliably data link layer under it ... I wonder if it really buys you anything in performance? chris
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: Tue, 12-May-87 17:38:03 EDT From: ROODE@BIONET-20.ARPA (David Roode) To: comp.protocols.tcp-ip Subject: mx-existence and header etiquette
Phase-in timetables for defacto standards are generally informal. What's the feeling about the use of host names that are only valid where there is support for both a host name resolver and MX name server domain entries? It seems reasonable for forwarding hosts to show up in the From: header as a courtesy to those hosts who do not yet support MX-existence. Is this support a "required" or an "optional" part of name resolvers? At least considering that on some of the networks composing the internet name server use is optional, some period of visibilty for forwarding makes sense. Apparently RELAY.CS.NET does follow this principle, but not all the hosts relaying UUCP hosts' mail to the Internet do. -------
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: Tue, 12-May-87 17:39:27 EDT From: kent@DECWRL.DEC.COM To: comp.protocols.tcp-ip Subject: Re: Dial-up TCP/IP (was interactive SMTP over phone lines)
We use SLIP (with some header compression) for dialup