|
|
ARCHIVE: TCP-IP Distribution List - Archives (1985)
DOCUMENT: TCP-IP Distribution List for June 1985 (266 messages, 74203 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1985/06.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Sat, 1-Jun-85 12:46:38 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: ARPANET/MILNET performance statistics
From: mills@dcn6.arpa Folks, Responding to Vint's request, here are some relevant data covering the ARPANET/MILNET gateway performance. The data have been extracted from the lastest weekly report produced by BBN and cover only the ARPANET/MILNET gateways, which represent only seven out of the 38 operational BBN core gateways. (Who knows how many non-core gateways there are out there...) The period covered by these data cover just short of a six-day period and detail the average and peak throughputs and loss rates. The totals shown are for all of the 38 gateways. Comments follow the tables. Total Throughput GWY RCVD RCVD IP % IP DEST % DST NAME DGRAMS BYTES ERRORS ERRORS UNRCH UNRCH ---------------------------------------------------------------------- MILARP 4,169,046 306,185,112 273 0.00% 7,153 0.17% MILBBN 4,638,747 272,396,860 458 0.00% 30,045 0.65% MILDCE 3,952,555 280,374,422 372 0.00% 23,747 0.60% MILISI 5,282,635 624,869,302 779 0.01% 20,353 0.39% MILLBL 2,896,764 175,123,126 143 0.00% 6,639 0.23% MILSAC 2,765,136 157,981,916 1,122 0.04% 10,588 0.38% MILSRI 2,133,985 117,968,018 169 0.00% 13,832 0.65% ---------------------------------------------------------------------- TOTALS 92,368,009 5,768,504,913 1,556,736 1.69% 190,545 0.21% GWY SENT SENT DROPPED % DROPPED NAME DGRAMS BYTES DGRAMS DGRAMS ------------------------------------------------------- MILARP 4,146,989 295,751,188 101,471 2.39% MILBBN 4,669,813 276,807,235 157,068 3.25% MILDCE 3,942,271 284,077,034 59,404 1.48% MILISI 5,138,585 577,311,096 247,222 4.59% MILLBL 2,877,744 174,574,553 55,537 1.89% MILSAC 2,792,073 165,159,590 13,393 0.48% MILSRI 2,156,255 127,256,463 53,483 2.42% ------------------------------------------------------- TOTALS 92,523,789 5,721,526,805 1,466,274 1.56% Note that the load balancing, while not optimal, is not too bad. The data do now show, of course, the extent of the double-hop inefficiencies pointed out previously. The ARPANET/MILNET gateways see fewer IP errors than average, but somewhat more broken networks and dropped packets than average. ====================================================== Mean Throughput (per second) and Size (bytes per datagram) GWY RCVD RCVD IP AVG BYTES NAME DGRAMS BYTES ERRORS PER DGRAM -------------------------------------------------------- MILARP 8.14 597.90 0.00 73.44 MILBBN 9.06 531.92 0.00 58.72 MILDCE 7.72 547.50 0.00 70.93 MILISI 10.32 1220.21 0.00 118.29 MILLBL 5.66 341.97 0.00 60.45 MILSAC 5.40 308.50 0.00 57.13 MILSRI 4.17 230.36 0.00 55.28 GWY SENT SENT DROPPED AVG BYTES NAME DGRAMS BYTES DGRAMS PER DGRAM ------------------------------------------------------- MILARP 8.10 577.53 0.20 71.32 MILBBN 9.12 540.53 0.31 59.28 MILDCE 7.70 554.73 0.12 72.06 MILISI 10.03 1127.34 0.48 112.35 MILLBL 5.62 340.90 0.11 60.66 MILSAC 5.45 322.51 0.03 59.15 MILSRI 4.21 248.50 0.10 59.02 These values are way below the maximum throughput of the LSI-11 gateways (about 200 packets/sec); however, the average size is very small relative to the maximum ARPANET/MILNET packet size of 1007 octets. One would expect the resource crunch to be the limited buffer memory available in the present LSI-11 implementation. Note that BBN is working actively toward a dramatic increase in available memory, as noted previously. ====================================================== Peak Throughput (sum of datagrams/sec, input + output, time is time of data collection) GWY TOTAL TIME DROP TIME NAME T'PUT OF DAY RATE OF DAY ------------------------------------------------------------------------ MILARP 47.28 5/24 09:16 27.26% 5/25 22:04 MILBBN 39.53 5/23 15:32 20.70% 5/24 02:18 MILDCE 36.67 5/24 08:02 26.12% 5/24 17:59 MILISI 44.45 5/23 15:02 32.39% 5/21 16:08 MILLBL 37.76 5/22 19:43 34.91% 5/24 12:02 MILSAC 36.91 5/23 13:03 5.75% 5/21 08:53 MILSRI 22.78 5/24 08:47 24.89% 5/21 16:08 Even under peak loads the gateway horsepower is not particularily taxed; however, the buffering is obviously suffering a good deal. The times of peak throughputs do not seem to correlate with the times of peak drop rates, which tends to confirm that most of the drops occur in bunches under conditions approaching congestive collapse. The instrumentation in our gateway beteen the ARPANET and four local nets, some of which are connected by medium-speed (4800/9600 bps) lines, tends to support the above observations and conclusions. We see intense spasms on the part of some hosts (names provided upon request) which clearly are to blame for almost all of the congestion observed here. These hosts apparently have been optimized to operate well on local Ethernets with small delays and tend to bombard the long-haul paths with vast numbers of retransmissions over very short intervals. I would bet a wadge of packets against a MicroVAX-II that the prime cause for the braindamage is ARP and the unfortunately common implementation that loses the first data packet during the address-resolution cycle. If this is fixed, I bet the tendency to err on the low side of retransmission estimates would go away. There are other causes of packet spasms that have been detailed in many of my previous messages. Happily, some have gone away. Those remaining symptoms indicate continuing inefficiencies in piggybacking and send/ack policies leading to tinygram floods (with TELNET, in particular). The sad fact is that these problems have been carefully documented and are not hard to fix; however, it takes only a few bandits without these fixes to torpedo the entire Internet performance. Dave -------
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: 1 Jun 85 17:59:49 PDT From: Murray.pa@Xerox.ARPA To: "J. Noel Chiappa" <JNC@MIT-XX.ARPA> Cc: Murray.pa@Xerox.ARPA, TCP-IP@SRI-NIC.ARPA Subject: Re: MILNET/ARPANET performance
I think "adjusting the timers" would help more than you give it credit for. From my experience, the single biggest problem on large networks is retransmitting too soon and too often. Most code gets debugged in a local environment that doesn't have gateways dropping packets because the next phone line (or net or..) is overloaded. People tighten down the timers to make things "work better". Unfortunatley, the sociology of this problem doesn't help to get it fixed. If you increase your timeouts, you don't get any positive rewards. It's only when almost everybody does it that anybody will get the benefits. Even then, the finks that don't cooperate get as much benefit as everybody else.
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Sat, 1-Jun-85 21:53:38 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: MILNET/ARPANET performance
From: Murray.pa@Xerox.ARPA I think "adjusting the timers" would help more than you give it credit for. From my experience, the single biggest problem on large networks is retransmitting too soon and too often. Most code gets debugged in a local environment that doesn't have gateways dropping packets because the next phone line (or net or..) is overloaded. People tighten down the timers to make things "work better". Unfortunatley, the sociology of this problem doesn't help to get it fixed. If you increase your timeouts, you don't get any positive rewards. It's only when almost everybody does it that anybody will get the benefits. Even then, the finks that don't cooperate get as much benefit as everybody else.
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Sat 1 Jun 85 22:33:56-EDT From: Lixia Zhang <Lixia@MIT-XX.ARPA> To: Murray.pa@XEROX.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: MILNET/ARPANET performance
I would support Noel's view point that "adjusting the timer will not help
much" in an overloaded net. Consider the following arguments:
- Timers, in general, are not shorter that a normal round-trip delay,
even in the case as you mentioned, "most code gets debugged in a local
environment".
- Therefore in most cases, if there is a series of timeouts, it is
started with jammed or lost packets. This means that somewhere in the
net gets overloaded by CURRENTLY offered data traffic.
- The window size = outstanding data = traffic load offered to the net.
- Therefore without reducing the window size
-> no reduction on network load
-> no help to the overloaded net.
- It is true that retransmitting too soon and too often will further damage
the situation, but simply adjusting the timer to hold up retransmission
longer will NOT resolve the congestion.
Lixia
-------
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Sun, 2-Jun-85 00:15:33 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: MILNET/ARPANET performance
From: Lixia Zhang <Lixia@MIT-XX.ARPA>
I would support Noel's view point that "adjusting the timer will not help
much" in an overloaded net. Consider the following arguments:
- Timers, in general, are not shorter that a normal round-trip delay,
even in the case as you mentioned, "most code gets debugged in a local
environment".
- Therefore in most cases, if there is a series of timeouts, it is
started with jammed or lost packets. This means that somewhere in the
net gets overloaded by CURRENTLY offered data traffic.
- The window size = outstanding data = traffic load offered to the net.
- Therefore without reducing the window size
-> no reduction on network load
-> no help to the overloaded net.
- It is true that retransmitting too soon and too often will further damage
the situation, but simply adjusting the timer to hold up retransmission
longer will NOT resolve the congestion.
Lixia
-------
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 2 Jun 1985 05:04-EDT From: CERF@USC-ISI.ARPA To: mills@DCN6.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: ARPANET/MILNET performance statistics
Dave, Thanks very much for a most helpful summary. One thing which I note about the MILISI gateway, in addition to its having far more traffic that most others is that its packet size (per datagram) is larger than a single packet message, assuming the avg bytes you show do NOT include all the TCP/IP header bytes which must fit inside the text of a single packet message. If memory serves, these messages have room for at most 1008 bits or 126 bytes, some of which have to be given over to IP or TCP header. If I'm correct in this analysis, the MILISI gateway is injecting a good deal of multi-packet traffic which puts a potential strain on the current imp end/end protocol. I note that MILISI has a higher rate of datagram dropping - one might guess this is a result of increased buffer demands and possibly increased incidence of timeouts for multipacket transmission permission? Dave is right about the need to fix those wayward implementations which try to treat all nets as if they are identical in performance. To borrow from Jack Haverty: You can fool some of gateways all of the time and all of the gateways, some of the time, but you can't... The whole SYSTEM has to be thought of as a system and all parts need to meet some standards of performance and adaptation. If this is not achievable (and it's a big challenge) then nets and gateways need to find ways to cut off identifiable abusers. Vint
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 2 Jun 1985 13:22:55 PDT From: POSTEL@USC-ISIF.ARPA To: TCP-IP@SRI-NIC.ARPA Subject: re: MILNET/ARPANET Performance
Folks: I think that adjusting your times may still have a big effect on your own performance. Looking at the numbers Dave Mills forwarded from the Gateway monitoring data collected by BBN one can see that the typical gateway is receiving about 5 to 10 datagrams per second (maybe 20 datagrams per second during the peak hour of the week). If one is sending retransmissions at the rate of one per second then one is contributing about 10% to 20% of the load on the gateway (maybe only 5% at the gateway's buisest time). I think these numbers are still big enough that ones' own traffic is not totally lost in the vast sea of traffic contributed by others. I think there is not as much going on in the network as we commonly asume, and i think that one still as a little bit of leverage on influencing the destiny of one's own datagrams. --jon. -------
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Sun, 2-Jun-85 17:17:33 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: re: MILNET/ARPANET Performance
From: POSTEL@USC-ISIF.ARPA Folks: I think that adjusting your times may still have a big effect on your own performance. Looking at the numbers Dave Mills forwarded from the Gateway monitoring data collected by BBN one can see that the typical gateway is receiving about 5 to 10 datagrams per second (maybe 20 datagrams per second during the peak hour of the week). If one is sending retransmissions at the rate of one per second then one is contributing about 10% to 20% of the load on the gateway (maybe only 5% at the gateway's buisest time). I think these numbers are still big enough that ones' own traffic is not totally lost in the vast sea of traffic contributed by others. I think there is not as much going on in the network as we commonly asume, and i think that one still as a little bit of leverage on influencing the destiny of one's own datagrams. --jon. -------
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Mon, 3-Jun-85 06:03:27 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: ARPANET/MILNET performance statistics
From: CERF@USC-ISI.ARPA Dave, Thanks very much for a most helpful summary. One thing which I note about the MILISI gateway, in addition to its having far more traffic that most others is that its packet size (per datagram) is larger than a single packet message, assuming the avg bytes you show do NOT include all the TCP/IP header bytes which must fit inside the text of a single packet message. If memory serves, these messages have room for at most 1008 bits or 126 bytes, some of which have to be given over to IP or TCP header. If I'm correct in this analysis, the MILISI gateway is injecting a good deal of multi-packet traffic which puts a potential strain on the current imp end/end protocol. I note that MILISI has a higher rate of datagram dropping - one might guess this is a result of increased buffer demands and possibly increased incidence of timeouts for multipacket transmission permission? Dave is right about the need to fix those wayward implementations which try to treat all nets as if they are identical in performance. To borrow from Jack Haverty: You can fool some of gateways all of the time and all of the gateways, some of the time, but you can't... The whole SYSTEM has to be thought of as a system and all parts need to meet some standards of performance and adaptation. If this is not achievable (and it's a big challenge) then nets and gateways need to find ways to cut off identifiable abusers. Vint
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Monday, 3 Jun 1985 10:59-PDT From: imagen!geof@SU-SHASTA.ARPA To: shasta!tcp-ip@sri-nic Subject: Re: MILNET/ARPANET performance
To summarize the last few messages: 1.Currently, many hosts retransmit too often. This is a major source of congestion, which can be alleviated by forcing hosts to use better algorithms for their timeouts, including (but not limited to) longer initial timeouts. 2.After we do this (if we can do this), congestion in the network will still be a problem, which according to Lixia Zhang's and Noel Chiappa's arguments, can only be solved by controlling the entry of packets into the internet. Clearly item 1 is important, and easier to carry out. Item 2 is an equally valid problem. - Geof Cooper
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Monday, 3 Jun 1985 11:23-PDT From: imagen!geof@Berkeley To: tcp-ip@sri-nic Subject: Re: Floods of tinygrams from telnet hosts
The worst offenders of the tinygram explosions seen by Dave Mills are probably Unix systems running server telnet. Every Unix TCP implementation I've seen (save one) has the characteristic that packets are sent whenever a unix WRITE(I) call is made. In many applications, this happens once per character. Unix also makes it very difficult to heuristically combine this flood of characters into larger packets (except on retransmission), through a combination of factors including interfaces that were designed for blocking system calls, and incredibly poor resolution of application-level timers. The one implementation I've seen that solves this problem uses the algorithm that John Nagle of Ford Aerospace developed. My understanding of it is (John, please correct any innaccuracies) that a TCP implementation will emit a new packet only under the following situations: - Its internal buffers are full (i.e., it is ready to send a full sized packet) - All outstanding data it has sent has been acknowledged by the remote TCP. When communicating over a local net, this algorithm works fine for telnet, since the intercharacter time is typically less than the connection round trip time. Whenever the intercharacter time of the TCP client becomes greater than the round trip time, the algorithm naturally divides the data to be sent into equally sized packets, based on the ratio of intercharacter time to round trip time. In the case of FTP-like connections, the algorithm degenerates into the current behavior, since the internal buffers are always full. Will someone please implement this on a 4.2 unix? Then maybe I'll be able to get decent response from APL when I telnet into the 4.2 machine on the local ethernet! - Geof
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 3 Jun 1985 10:49:57 EDT From: MILLS@USC-ISID.ARPA To: Lixia@MIT-XX.ARPA, Murray.pa@XEROX.ARPA Cc: tcp-ip@SRI-NIC.ARPA, MILLS@USC-ISID.ARPA Subject: Re: MILNET/ARPANET performance
In response to the message sent Sat 1 Jun 85 22:33:56-EDT from Lixia@MIT-XX.ARPA Lixia, A large number of hosts have been observed here using initial retransmission timeouts in the one-to-two second range, which has been repeatedly noted as being too short (see RFC-889). When a couple of these WMWs gang up on a busy gateway, instant congestion occurs and doesn't go away until the hosts time out the ACK for their SYN, usually a minute or so. The SYNfull gateway meanwhile is dropping lots of packets for other clients, who themselves are ratcheting the retransmission-timeout estimate upwards. The system is obviously unstable, even when the gateway was comfortably underloaded to begin with. All it takes is a pulse of traffic sufficient to topple the gateway over its buffer limit. In other words, your argument has great merit; however the assumption that retransmission timeouts are always longer than the roundtrip time is not correct for many players in this circus. Dave -------
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 3 Jun 1985 10:59:37 EDT From: MILLS@USC-ISID.ARPA To: CERF@USC-ISI.ARPA, mills@DCN6.ARPA Cc: tcp-ip@SRI-NIC.ARPA, MILLS@USC-ISID.ARPA Subject: Re: ARPANET/MILNET performance statistics
In response to the message sent 2 Jun 1985 05:04-EDT from CERF@USC-ISI.ARPA Vint, The datagram sizes shown in my data include the IP and TCP headers, so a lot more gateways than just ISI are chirping multi-packet messages. From previous reports, I would not count the ISI data as typical - there might be something special going on there. I'll alert the field operatives... Dave -------
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Mon, 3-Jun-85 11:51:43 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: MILNET/ARPANET performance
From: MILLS@USC-ISID.ARPA In response to the message sent Sat 1 Jun 85 22:33:56-EDT from Lixia@MIT-XX.ARPA Lixia, A large number of hosts have been observed here using initial retransmission timeouts in the one-to-two second range, which has been repeatedly noted as being too short (see RFC-889). When a couple of these WMWs gang up on a busy gateway, instant congestion occurs and doesn't go away until the hosts time out the ACK for their SYN, usually a minute or so. The SYNfull gateway meanwhile is dropping lots of packets for other clients, who themselves are ratcheting the retransmission-timeout estimate upwards. The system is obviously unstable, even when the gateway was comfortably underloaded to begin with. All it takes is a pulse of traffic sufficient to topple the gateway over its buffer limit. In other words, your argument has great merit; however the assumption that retransmission timeouts are always longer than the roundtrip time is not correct for many players in this circus. Dave -------
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Mon 3 Jun 85 11:55:40-EDT From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA> To: Murray.pa@XEROX.ARPA Cc: TCP-IP@SRI-NIC.ARPA, JNC@MIT-XX.ARPA Subject: Re: MILNET/ARPANET performance
How true that one can ruin it for all. One definite facet of congestion control (when we eventually implement it) is server penalization of hosts that don't obey the rules. Gotta have some feedback in the system to encourage people to fix lossage. Noel -------
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Mon, 3 Jun 85 12:40:10 EDT From: Ron Natalie <ron@BRL.ARPA> To: CERF@USC-ISI.ARPA Cc: mills@DCN6.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: ARPANET/MILNET performance statistics
One observation: MILISI is the gateway that EGP tells my gateways to use for all the nets on the other side of the bridges. Assuming this is true for both sides of the house, it would seem that this is the gateway used for peoples little ethernets to talk through to get to the otherside. Most local nets have higher MTU's than the IMP 1008 (typically 1536). This results in their gateways sending lots of fragmented datagrams all over the place. Since most of the LANs derive choose the MIL/ARPA bridge from the EGP information, ISI may bear the brunt of the fractured ethernet traffic. IP fragmentation is admittedly a bad thing to do on a regular basis. BRL avoids this by keeping most of our LAN's at 1008 (for historical reasons mostly, the gateways originally didn't know how to fragment). -Ron
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Mon, 3-Jun-85 12:51:50 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: ARPANET/MILNET performance statistics
From: MILLS@USC-ISID.ARPA In response to the message sent 2 Jun 1985 05:04-EDT from CERF@USC-ISI.ARPA Vint, The datagram sizes shown in my data include the IP and TCP headers, so a lot more gateways than just ISI are chirping multi-packet messages. From previous reports, I would not count the ISI data as typical - there might be something special going on there. I'll alert the field operatives... Dave -------
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Mon, 3-Jun-85 13:53:37 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: MILNET/ARPANET performance
From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA> How true that one can ruin it for all. One definite facet of congestion control (when we eventually implement it) is server penalization of hosts that don't obey the rules. Gotta have some feedback in the system to encourage people to fix lossage. Noel -------
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Mon, 3 Jun 85 14:33:44 EDT From: Marianne Gardner <mgardner@BBNCCY.ARPA> To: MILLS@usc-isid.arpa Cc: CERF@usc-isi.arpa, mills@dcn6.arpa, tcp-ip@sri-nic.arpa, mgardner@BBNCCY.ARPA Subject: Re: ARPANET/MILNET performance statistics
Dave, I must disagree with both you and Vint. It is typical for ISI to have an average datagram size over 100 bytes. ISI does not have a disproportionate amount of traffic and drops fewer packets than most of the mailbridges. Marianne
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 3 Jun 1985 14:41:36 EDT From: INCO@USC-ISID.ARPA To: tcp-ip@SRI-NIC.ARPA Cc: protocols@RUTGERS.ARPA Subject: DECNET issues
I am interested in anyone who has used or worked with DECNET
as regards to performance, apllications,functionality, etc. Specifically,
I am interested in any documentation on these issues over and above
what is covered in literature provoided by DECNET, or opinions by
individuals who have worked with DECNET itself. Thank you.
Steve Sutkowski
Inco at Usc-Isid
-------
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Mon, 3-Jun-85 15:04:34 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: MILNET/ARPANET performance
From: imagen!geof@SU-SHASTA.ARPA To summarize the last few messages: 1.Currently, many hosts retransmit too often. This is a major source of congestion, which can be alleviated by forcing hosts to use better algorithms for their timeouts, including (but not limited to) longer initial timeouts. 2.After we do this (if we can do this), congestion in the network will still be a problem, which according to Lixia Zhang's and Noel Chiappa's arguments, can only be solved by controlling the entry of packets into the internet. Clearly item 1 is important, and easier to carry out. Item 2 is an equally valid problem. - Geof Cooper
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 3 Jun 1985 15:33:00 EDT From: MILLS@USC-ISID.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: Multiple homes considered taxable
Folks, I just caught NIC sending mail to local-host 128.4.0.9 off our ARPANET gateway from its MILNET address, rather than its ARPANET address. Certainly this clutters up the ARPANET/MILNET gateways, as well as offends the Principle of Least Astonishment; however, I can easily see how this can come about, since hosts don't know about gateway hops. Our GADS task force should chew on this one. Dave -------
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 3 Jun 1985 15:47:08 EDT From: MILLS@USC-ISID.ARPA To: mgardner@BBNCCY.ARPA Cc: CERF@USC-ISI.ARPA, mills@DCN6.ARPA, tcp-ip@SRI-NIC.ARPA, MILLS@USC-ISID.ARPA Subject: Re: ARPANET/MILNET performance statistics
In response to your message sent Mon, 3 Jun 85 14:33:44 EDT Marianne, Your comments do not jibe with the data in my message - MILISI leads the pack in throughput, size and almost all categories of breakage. You might have taken umbrage if I tattled on ISI (as against MILISI), but my message clearly addressed the mailbridges only. Dave -------
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Mon, 3 Jun 85 16:13:14 EDT From: Marianne Gardner <mgardner@BBNCCY.ARPA> To: MILLS@usc-isid.arpa Cc: mgardner@BBNCCY.ARPA, CERF@usc-isi.arpa, mills@dcn6.arpa, tcp-ip@sri-nic.arpa Subject: Re: ARPANET/MILNET performance statistics
Dave,
You data suffers taking too small a sample. Yes, last week MILISI had
more traffic than the other bridges, but this is not the usual case as the
summaries below will show. Let me say again, that if you look at the trap
reports and throughput summaries for the last few months, you will not find
that MILISI has more problems than the other mailbridges.
Sorry if my shortening the name of MILISI confused you.
The data that follows covers 7 day periods, from Monday to the following
Sunday. The date indicated is the Sunday that ends the collection period.
date: 4/14 (Sun)
GTWY HOURS RCVD DST RCVD PPS SENT PPS AVG
COVERED DGRAMS UNRCH DGRAMS DGRAMS BYTES
MILARP 162.00 5,491,493 0.09 9.42 9.24 129.35
MILDCE 162.00 5,445,388 0.72 9.34 9.24 70.18
MILISI 162.00 4,976,827 0.58 8.53 8.48 117.84
MILLBL 162.25 3,800,470 2.64 6.51 6.11 65.16
MILSAC 162.00 2,591,494 0.17 4.44 4.48 63.04
MILSRI 162.00 2,162,412 2.08 3.71 3.70 59.10
date: 4/21 (Sun)
GTWY HOURS RCVD DST RCVD PPS SENT PPS AVG
COVERED DGRAMS UNRCH DGRAMS DGRAMS BYTES
MILARP 155.50 4,184,138 0.29 7.47 7.44 79.09
MILISI 158.75 4,914,047 0.58 8.60 8.66 114.79
MILLBL 158.75 3,934,242 0.59 6.88 6.76 78.86
MILSAC 158.75 2,667,978 0.81 4.67 4.70 61.66
MILSRI 158.75 2,051,680 1.59 3.59 3.62 59.14
date: 5/5 (Sun)
GTWY HOURS RCVD DST RCVD PPS SENT PPS AVG
COVERED DGRAMS UNRCH DGRAMS DGRAMS BYTES
MILARP 164.25 4,550,474 1.40 7.70 7.75 74.89
MILBBN 164.25 5,622,661 0.67 9.51 9.56 60.07
MILDCE 161.75 4,467,564 0.94 7.67 7.66 77.32
MILISI 164.25 5,190,179 0.46 8.78 8.64 115.16
MILLBL 164.25 3,797,215 0.41 6.42 5.94 63.03
MILSAC 164.25 3,120,124 0.49 5.28 5.21 68.68
MILSRI 164.25 2,058,651 0.42 3.48 3.57 65.51
date: 5/12 (Sun)
GTWY HOURS RCVD DST RCVD PPS SENT PPS AVG
MILARP 161.25 4,765,258 0.34 8.21 8.19 74.53
MILBBN 161.25 4,809,526 0.81 8.29 8.38 60.88
MILDCE 161.25 4,643,647 0.56 8.00 7.96 78.24
MILISI 161.25 5,059,553 0.50 8.72 8.65 96.73
MILLBL 161.25 3,501,986 0.30 6.03 5.93 62.55
MILSAC 161.25 3,073,519 0.49 5.29 5.22 66.44
MILSRI 161.25 1,994,121 0.17 3.44 3.54 66.18
date: 5/19 (Sun)
GTWY HOURS RCVD DST RCVD PPS SENT PPS AVG
COVERED DGRAMS UNRCH DGRAMS DGRAMS BYTES
MILARP 162.00 4,442,049 0.23 7.62 7.62 72.99
MILBBN 161.75 5,030,583 0.81 8.64 8.78 61.53
MILDCE 159.50 4,428,993 0.73 7.71 7.67 90.27
MILISI 162.00 4,866,970 0.55 8.35 8.37 105.50
MILLBL 162.00 3,103,610 0.15 5.32 5.23 64.42
MILSAC 162.00 2,990,150 0.50 5.13 5.17 64.61
MILSRI 162.00 2,046,546 0.74 3.51 3.59 57.72
date: 5/26 (Sun)
GTWY HOURS RCVD DST RCVD PPS SENT PPS AVG
COVERED DGRAMS UNRCH DGRAMS DGRAMS BYTES
MILARP 142.25 4,169,046 0.17 8.14 8.10 71.32
MILBBN 142.25 4,638,747 0.65 9.06 9.12 59.28
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Mon, 3-Jun-85 16:16:33 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: DECNET issues
From: INCO@USC-ISID.ARPA
I am interested in anyone who has used or worked with DECNET
as regards to performance, apllications,functionality, etc. Specifically,
I am interested in any documentation on these issues over and above
what is covered in literature provoided by DECNET, or opinions by
individuals who have worked with DECNET itself. Thank you.
Steve Sutkowski
Inco at Usc-Isid
-------
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Mon, 3 Jun 85 16:27:54 edt From: James O'Toole <james@gyre> To: cerf@usc-isi Cc: tcp-ip@nic Subject: Re: ARPANET/MILNET performance statistics
Vint, Your message said "1008 bits or 126 bytes" but the IMP really handles 1008 *bytes*. I didn't notice that the average packet sizes were ever higher than that, which would surprise me. Am I missing the point here, or did you mix your units? --Jim P.S. Hmmm, isn't that really 1006, not 1008?
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Mon 3 Jun 85 16:36:17-EDT From: Ken Rossman <sy.Ken@CU20B.ARPA> To: INCO@USC-ISID.ARPA, tcp-ip@SRI-NIC.ARPA Cc: protocols@RUTGERS.ARPA Subject: Re: DECNET issues
We run a fairly extensive DECnet here at Columbia University, which also stretches to various other schools. We also run TCP/IP. The functionality of the two nets actually complement each other, and they are both useful to have around for different reasons. If you can be more specific about the types of questions you want answered, I can be more specific in my reply to your queries. /Ken -------
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Mon, 3-Jun-85 17:14:48 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: ARPANET/MILNET performance statistics
From: Marianne Gardner <mgardner@BBNCCY.ARPA> Dave, I must disagree with both you and Vint. It is typical for ISI to have an average datagram size over 100 bytes. ISI does not have a disproportionate amount of traffic and drops fewer packets than most of the mailbridges. Marianne
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Mon, 3 Jun 85 18:23:08 CDT From: Mike Caplinger <mike@rice.ARPA> To: tcp-ip@sri-nic.ARPA
Does somebody have a 4.2 UDP time setting program, and a daemon for
same? I'm sure the availability of the former would lessen the load on
DCN fuzzballs.
Also, SMI take note; I assume the Sun rdate is TCP-based. Maybe there
should be a UDP version.
- Mike
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Mon, 3-Jun-85 19:10:41 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: ARPANET/MILNET performance statistics
From: MILLS@USC-ISID.ARPA In response to your message sent Mon, 3 Jun 85 14:33:44 EDT Marianne, Your comments do not jibe with the data in my message - MILISI leads the pack in throughput, size and almost all categories of breakage. You might have taken umbrage if I tattled on ISI (as against MILISI), but my message clearly addressed the mailbridges only. Dave -------
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Mon, 3-Jun-85 20:42:22 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: ARPANET/MILNET performance statistics
From: James O'Toole <james@gyre> Vint, Your message said "1008 bits or 126 bytes" but the IMP really handles 1008 *bytes*. I didn't notice that the average packet sizes were ever higher than that, which would surprise me. Am I missing the point here, or did you mix your units? --Jim P.S. Hmmm, isn't that really 1006, not 1008?
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Mon, 3-Jun-85 21:11:35 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: DECNET issues
From: Ken Rossman <sy.Ken@CU20B.ARPA> We run a fairly extensive DECnet here at Columbia University, which also stretches to various other schools. We also run TCP/IP. The functionality of the two nets actually complement each other, and they are both useful to have around for different reasons. If you can be more specific about the types of questions you want answered, I can be more specific in my reply to your queries. /Ken -------
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 03 Jun 85 22:45:34 EST (Mon) From: Christopher A Kent <cak@Purdue.ARPA> To: Mike Caplinger <mike@rice.arpa> Cc: tcp-ip@sri-nic.arpa
I have such a pair of programs; I just dusted off my TCP versions and made them mumble UDP. Dave should be much happier now. I'll put them on purdue-merlin for anonymous FTP, in the file pub/dated.flar. Cheers, chris ----------
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: Mon, 3-Jun-85 22:00:28 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: ARPANET/MILNET performance statistics
From: Marianne Gardner <mgardner@BBNCCY.ARPA>
Dave,
You data suffers taking too small a sample. Yes, last week MILISI had
more traffic than the other bridges, but this is not the usual case as the
summaries below will show. Let me say again, that if you look at the trap
reports and throughput summaries for the last few months, you will not find
that MILISI has more problems than the other mailbridges.
Sorry if my shortening the name of MILISI confused you.
The data that follows covers 7 day periods, from Monday to the following
Sunday. The date indicated is the Sunday that ends the collection period.
date: 4/14 (Sun)
GTWY HOURS RCVD DST RCVD PPS SENT PPS AVG
COVERED DGRAMS UNRCH DGRAMS DGRAMS BYTES
MILARP 162.00 5,491,493 0.09 9.42 9.24 129.35
MILDCE 162.00 5,445,388 0.72 9.34 9.24 70.18
MILISI 162.00 4,976,827 0.58 8.53 8.48 117.84
MILLBL 162.25 3,800,470 2.64 6.51 6.11 65.16
MILSAC 162.00 2,591,494 0.17 4.44 4.48 63.04
MILSRI 162.00 2,162,412 2.08 3.71 3.70 59.10
date: 4/21 (Sun)
GTWY HOURS RCVD DST RCVD PPS SENT PPS AVG
COVERED DGRAMS UNRCH DGRAMS DGRAMS BYTES
MILARP 155.50 4,184,138 0.29 7.47 7.44 79.09
MILISI 158.75 4,914,047 0.58 8.60 8.66 114.79
MILLBL 158.75 3,934,242 0.59 6.88 6.76 78.86
MILSAC 158.75 2,667,978 0.81 4.67 4.70 61.66
MILSRI 158.75 2,051,680 1.59 3.59 3.62 59.14
date: 5/5 (Sun)
GTWY HOURS RCVD DST RCVD PPS SENT PPS AVG
COVERED DGRAMS UNRCH DGRAMS DGRAMS BYTES
MILARP 164.25 4,550,474 1.40 7.70 7.75 74.89
MILBBN 164.25 5,622,661 0.67 9.51 9.56 60.07
MILDCE 161.75 4,467,564 0.94 7.67 7.66 77.32
MILISI 164.25 5,190,179 0.46 8.78 8.64 115.16
MILLBL 164.25 3,797,215 0.41 6.42 5.94 63.03
MILSAC 164.25 3,120,124 0.49 5.28 5.21 68.68
MILSRI 164.25 2,058,651 0.42 3.48 3.57 65.51
date: 5/12 (Sun)
GTWY HOURS RCVD DST RCVD PPS SENT PPS AVG
MILARP 161.25 4,765,258 0.34 8.21 8.19 74.53
MILBBN 161.25 4,809,526 0.81 8.29 8.38 60.88
MILDCE 161.25 4,643,647 0.56 8.00 7.96 78.24
MILISI 161.25 5,059,553 0.50 8.72 8.65 96.73
MILLBL 161.25 3,501,986 0.30 6.03 5.93 62.55
MILSAC 161.25 3,073,519 0.49 5.29 5.22 66.44
MILSRI 161.25 1,994,121 0.17 3.44 3.54 66.18
date: 5/19 (Sun)
GTWY HOURS RCVD DST RCVD PPS SENT PPS AVG
COVERED DGRAMS UNRCH DGRAMS DGRAMS BYTES
MILARP 162.00 4,442,049 0.23 7.62 7.62 72.99
MILBBN 161.75 5,030,583 0.81 8.64 8.78 61.53
MILDCE 159.50 4,428,993 0.73 7.71 7.67 90.27
MILISI 162.00 4,866,970 0.55 8.35 8.37 105.50
MILLBL 162.00 3,103,610 0.15 5.32 5.23 64.42
MILSAC 162.00 2,990,150 0.50 5.13 5.17 64.61
MILSRI 162.00 2,046,546 0.74 3.51 3.59 57.72
date: 5/26 (Sun)
GTWY HOURS RCVD DST RCVD PPS SENT PPS AVG
COVERED DGRAMS UNRCH DGRAMS DGRAMS BYTES
MILARP 142.25 4,169,046 0.17 8.14 8.10 71.32
MILBBN 142.25 4,638,747 0.65 9.06 9.12 59.28
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 3 Jun 1985 22:27:11 EDT From: MILLS@USC-ISID.ARPA To: mgardner@BBNCCY.ARPA Cc: CERF@USC-ISI.ARPA, mills@DCN6.ARPA, tcp-ip@SRI-NIC.ARPA, MILLS@USC-ISID.ARPA Subject: Re: ARPANET/MILNET performance statistics
In response to your message sent Mon, 3 Jun 85 16:13:14 EDT Marianne, I surely didn't mean to start a bluster here. Vint's original comment addressed the curiousity that MILISI datagrams were fatter than the others. Your data show this to be true in four of the five samples. My comment that MILISI exibited more breakage than the others was not intended as a blanket indictment and, in fact is not justified in view of your data. My suspicion that ISI is indeed special is confirmed both because of the consistently high datagram size, as well as the increasing share of the system load, going from number four at the beginning of your sample history consistently upwards to number one at the end. MILISI is again number one this week in both departments. My aside to Vint that I would "alert the field operatives" has come to pass and you have broken cover. Your next assignment, should you choose to accept it, is to tell us why. Dave -------
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 03 Jun 85 23:35:09 EST (Mon) From: Christopher A Kent <cak@Purdue.ARPA> To: tcp-ip@sri-nic.arpa Subject: Speaking of 4.2 time programs
Has anyone made the modifications to 4.2 to slave a system's clock to a Fuzzball host? chris ----------
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Tue, 4-Jun-85 01:12:35 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: ARPANET/MILNET performance statistics
From: MILLS@USC-ISID.ARPA In response to your message sent Mon, 3 Jun 85 16:13:14 EDT Marianne, I surely didn't mean to start a bluster here. Vint's original comment addressed the curiousity that MILISI datagrams were fatter than the others. Your data show this to be true in four of the five samples. My comment that MILISI exibited more breakage than the others was not intended as a blanket indictment and, in fact is not justified in view of your data. My suspicion that ISI is indeed special is confirmed both because of the consistently high datagram size, as well as the increasing share of the system load, going from number four at the beginning of your sample history consistently upwards to number one at the end. MILISI is again number one this week in both departments. My aside to Vint that I would "alert the field operatives" has come to pass and you have broken cover. Your next assignment, should you choose to accept it, is to tell us why. Dave -------
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: Tue, 4-Jun-85 01:52:22 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Floods of tinygrams from telnet hosts
From: imagen!geof@BERKELEY The worst offenders of the tinygram explosions seen by Dave Mills are probably Unix systems running server telnet. Every Unix TCP implementation I've seen (save one) has the characteristic that packets are sent whenever a unix WRITE(I) call is made. In many applications, this happens once per character. Unix also makes it very difficult to heuristically combine this flood of characters into larger packets (except on retransmission), through a combination of factors including interfaces that were designed for blocking system calls, and incredibly poor resolution of application-level timers. The one implementation I've seen that solves this problem uses the algorithm that John Nagle of Ford Aerospace developed. My understanding of it is (John, please correct any innaccuracies) that a TCP implementation will emit a new packet only under the following situations: - Its internal buffers are full (i.e., it is ready to send a full sized packet) - All outstanding data it has sent has been acknowledged by the remote TCP. When communicating over a local net, this algorithm works fine for telnet, since the intercharacter time is typically less than the connection round trip time. Whenever the intercharacter time of the TCP client becomes greater than the round trip time, the algorithm naturally divides the data to be sent into equally sized packets, based on the ratio of intercharacter time to round trip time. In the case of FTP-like connections, the algorithm degenerates into the current behavior, since the internal buffers are always full. Will someone please implement this on a 4.2 unix? Then maybe I'll be able to get decent response from APL when I telnet into the 4.2 machine on the local ethernet! - Geof
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Tue, 4-Jun-85 03:21:00 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: ARPANET/MILNET performance statistics
From: Ron Natalie <ron@BRL.ARPA> One observation: MILISI is the gateway that EGP tells my gateways to use for all the nets on the other side of the bridges. Assuming this is true for both sides of the house, it would seem that this is the gateway used for peoples little ethernets to talk through to get to the otherside. Most local nets have higher MTU's than the IMP 1008 (typically 1536). This results in their gateways sending lots of fragmented datagrams all over the place. Since most of the LANs derive choose the MIL/ARPA bridge from the EGP information, ISI may bear the brunt of the fractured ethernet traffic. IP fragmentation is admittedly a bad thing to do on a regular basis. BRL avoids this by keeping most of our LAN's at 1008 (for historical reasons mostly, the gateways originally didn't know how to fragment). -Ron
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: Tue, 4-Jun-85 03:57:01 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Speaking of 4.2 time programs
From: Christopher A Kent <cak@Purdue.ARPA> Has anyone made the modifications to 4.2 to slave a system's clock to a Fuzzball host? chris ----------
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: 4 Jun 1985 1116-PDT (Tuesday) From: Jeff Mogul <mogul@Navajo> To: Ron Natalie <ron@BRL.ARPA> Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Fragging ARPAnet gateways
IP fragmentation is admittedly
a bad thing to do on a regular basis. BRL avoids this by keeping most
of our LAN's at 1008 (for historical reasons mostly, the gateways
originally didn't know how to fragment).
One of the less successful performance "improvements" in 4.2BSD
was that the TCP tried to use 1024 byte segments, since this
allowed 4.2 to use page-remapping techniques instead of copying.
However, this is really a complete loss in our environment, where
we had Vaxen connected to a 3Mb ether which is gatewayed to the
ARPAnet (the current hardware situation is a little different).
FTPing from another 4.2 machine across the ARPAnet would seldom
work, because those 1024-byte segments turned into an almost-1024-
byte fragment followed by a tinygram. The local gateway dumps the
tinygram onto the ethernet almost immediately following the first
fragment, and the Vax interface (no buffering) drops back-to-back
packets, i.e., the tinygram. This happens over and over, so even
though 90% of the bytes are getting through, the segment is never
acked and the connection fizzles.
We solved this by hacking the TCP code to force 576-byte segments
unless it is sure that no gateway was in the path, in which
case it uses the LAN MTU. This works fine, and we can keep our
LAN MTUs high (1500 bytes) to reduce the packet counts in the
dominant case.
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 04 Jun 85 08:59:46 EDT (Tue) From: Mike Brescia <brescia@bbnccv> To: James O'Toole <james@gyre> Cc: tcp-ip@nic, brescia@bbnccv Subject: arpanet/milnet packet and message size
- arpanet message size Your local arpanet/milnet imp will accept messages from your host up to 1008-octets-less-one-bit (8063 bits) beyond the AHIP (arpanet host-imp protocol) leader. For those sites which use interfaces that handle data in units of 2 octets (vax or pdp11 and lhdh interface), this sets a practical limit of 1006 bytes. - significance of 126 octets The arpanet imps handle data internally and forward them among themselves using buffers and packets of "1008 bits or 126 bytes". Also, messages 126 octets or shorter are treated differently in the imp end-to-end exchanges (exchanges between the imp connected to the source host and that at the destination). Briefly, the "single packet" messages (126 or shorter) are sent directly, while longer "multi-packet" messages are sent only after the source imp has sent a short allocation request to the destination imp and gotten a reply. This is one reason why a data measurement a few years ago showed a throughput peak at packet size of 126, then smaller throughput until the packet size was increased beyond 4*126 octets. The imp end-to-end algorithms are currently being redesigned to relax these allocation delays, allow more than 8 messages at a time between hosts or gateways (mentioned in some other notes), and remove some other causes of host blocking where the imp delays accepting data from the host.
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Tue 4 Jun 85 12:25:58-PDT From: Mark Crispin <Crispin@SUMEX-AIM.ARPA> To: james@GYRE.ARPA Cc: cerf@USC-ISI.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: ARPANET/MILNET performance statistics
Jim -
An 1822 packet is 1008 bits, which is not only 126 bytes
but also 28 36-bit words. Hosts never see packets, they see
messages which can be up to 8159 bytes; that is, a 96 bit leader
plus 8 packets full of data minus 1 bit.
Many people erroneously confuse messages with packets, and
unfortunately a lot of host software does the same.
-- Mark --
-------
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Tue, 4-Jun-85 09:55:32 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: arpanet/milnet packet and message size
From: Mike Brescia <brescia@bbnccv> - arpanet message size Your local arpanet/milnet imp will accept messages from your host up to 1008-octets-less-one-bit (8063 bits) beyond the AHIP (arpanet host-imp protocol) leader. For those sites which use interfaces that handle data in units of 2 octets (vax or pdp11 and lhdh interface), this sets a practical limit of 1006 bytes. - significance of 126 octets The arpanet imps handle data internally and forward them among themselves using buffers and packets of "1008 bits or 126 bytes". Also, messages 126 octets or shorter are treated differently in the imp end-to-end exchanges (exchanges between the imp connected to the source host and that at the destination). Briefly, the "single packet" messages (126 or shorter) are sent directly, while longer "multi-packet" messages are sent only after the source imp has sent a short allocation request to the destination imp and gotten a reply. This is one reason why a data measurement a few years ago showed a throughput peak at packet size of 126, then smaller throughput until the packet size was increased beyond 4*126 octets. The imp end-to-end algorithms are currently being redesigned to relax these allocation delays, allow more than 8 messages at a time between hosts or gateways (mentioned in some other notes), and remove some other causes of host blocking where the imp delays accepting data from the host.
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Tue, 4-Jun-85 15:21:45 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Fragging ARPAnet gateways
From: Jeff Mogul <mogul@Navajo>
IP fragmentation is admittedly
a bad thing to do on a regular basis. BRL avoids this by keeping most
of our LAN's at 1008 (for historical reasons mostly, the gateways
originally didn't know how to fragment).
One of the less successful performance "improvements" in 4.2BSD
was that the TCP tried to use 1024 byte segments, since this
allowed 4.2 to use page-remapping techniques instead of copying.
However, this is really a complete loss in our environment, where
we had Vaxen connected to a 3Mb ether which is gatewayed to the
ARPAnet (the current hardware situation is a little different).
FTPing from another 4.2 machine across the ARPAnet would seldom
work, because those 1024-byte segments turned into an almost-1024-
byte fragment followed by a tinygram. The local gateway dumps the
tinygram onto the ethernet almost immediately following the first
fragment, and the Vax interface (no buffering) drops back-to-back
packets, i.e., the tinygram. This happens over and over, so even
though 90% of the bytes are getting through, the segment is never
acked and the connection fizzles.
We solved this by hacking the TCP code to force 576-byte segments
unless it is sure that no gateway was in the path, in which
case it uses the LAN MTU. This works fine, and we can keep our
LAN MTUs high (1500 bytes) to reduce the packet counts in the
dominant case.
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: Tue, 4 Jun 85 16:17:58 EDT From: Ron Natalie <ron@BRL.ARPA> To: Christopher A Kent <cak@PURDUE.ARPA> Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Speaking of 4.2 time programs
Perhaps all the MILNET/ARPANET loading is coming from everybody trying to use DCN machines to set their clocks. -Ron
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: Tue, 4-Jun-85 16:20:26 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: ARPANET/MILNET performance statistics
From: Mark Crispin <Crispin@SUMEX-AIM.ARPA>
Jim -
An 1822 packet is 1008 bits, which is not only 126 bytes
but also 28 36-bit words. Hosts never see packets, they see
messages which can be up to 8159 bytes; that is, a 96 bit leader
plus 8 packets full of data minus 1 bit.
Many people erroneously confuse messages with packets, and
unfortunately a lot of host software does the same.
-- Mark --
-------
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Tue, 4 Jun 85 16:24:09 EDT From: Ron Natalie <ron@BRL.ARPA> To: Jeff Mogul <mogul@SU-NAVAJO.ARPA> Cc: Ron Natalie <ron@BRL.ARPA>, tcp-ip@SRI-NIC.ARPA Subject: Re: Fragging ARPAnet gateways
Yes, we realized this to. Our gateway had slight software modifications to cope with this. Fortunately the Ethernet has a little buffering on the boards (at least Interlan does), unfortunately some of the other strange devices we use here, did not. -Ron
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Tue, 4 Jun 85 16:30:36 EDT From: Mike Muuss <mike@BRL.ARPA> To: imagen!geof@su-shasta.ARPA Cc: tcp-ip@sri-nic.ARPA Subject: Re: Floods of tinygrams from telnet hosts
Berkeley's latest TCP (which will eventually be released as 4.3 BSD) is improved in this regard; it also listens to ICMP source quenches. -M
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: Tue, 4-Jun-85 17:19:37 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Floods of tinygrams from telnet hosts
From: Mike Muuss <mike@BRL.ARPA> Berkeley's latest TCP (which will eventually be released as 4.3 BSD) is improved in this regard; it also listens to ICMP source quenches. -M
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: Tue, 4 Jun 85 19:36:20 EDT From: Ron Natalie <ron@BRL.ARPA> To: James O'Toole <james@GYRE.ARPA> Cc: cerf@USC-ISI.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: ARPANET/MILNET performance statistics
Actually IMP packets are 1008 bits, IMP regular messages (what we know as packets) are from 96 to 8159 bits. Subtracting 96 bits off for the IMP leader leaves 8063 bits which is 1007 octets and 7 bits left over (a septet, I suppose). -Ron
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Tue, 4 Jun 85 20:01 EDT From: "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: Fragmentation
What will it take to define some protocol for establishing reasonable segment lengths? Comments that appear every month or so seem to cry out for some IP/ICMP do-dah by which two hosts can get a good guess of the fragmentation situation in between each other. For a start, any TCP/IP where TCP can't ask for the hardware MTU of the most likely routing to a given address should be taken out and shot. After that, perhaps some sort of IP option could be added to which any gateway involved would add its hardware MTU. An exchange of these at the beginning of a connection would improve the picture no end.
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: 5 Jun 85 00:31:03 PDT From: Murray.pa@Xerox.ARPA To: tcp-ip@SRI-NIC.ARPA Cc: Murray.pa@Xerox.ARPA Subject: Re: Fragging ARPAnet gateways
There is another hack that's worth remembering if anybody is having troubles catching back-to-back packets: Slow down the transmitter. Some of our Ethernet drivers do that with only a few words of microcode. On the first (re)transmission, set the collision timer to 1ms. There are obviously variations and optimizations. The point is that it's trivial to implement and a small delay won't be noticed by most applications but it can be a lifesaver in a few critical cases. Credit where it's due dept: Ed Taft came up with this trick when our Alto based file servers couldn't keep up with our Dorados.
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 04 Jun 85 22:46:09 EDT (Tue) From: Dennis Rockwell <drockwel@CSNET-SH.ARPA> To: "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA> Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Fragmentation
A solution that I used in the later BBN 4.1 TCP/IP implementation was for the IP layer to pass to TCP the size of the largest fragment which went to make up the current IP packet. TCP then unilaterally restricted its segment size to twice the fragment size (less an appropriate fudge factor). This produces no tinygrams, although interfaces that can't handle back-to-back packets are still in trouble. Yes, it's a hack that violates level separation rules, but it made a big difference in practice. A useful facility that the SATNET folks have been good enough to provide are the IP echo hosts on the far side of satellite connections (goonhilly-echo for example). These switch the IP source and destination addresses and ship the packet out again. Since SATNET has the smallest MTU, the longest delay, and a penchant for dropping packets (this is not SATNET's fault; the speed mismatch between the ARPAnet and SATNET is ferocious and the gateway clogs), it's handy for testing TCP/IP implementations. It has been known to crash insufficiently bulletproofed software. Dennis Rockwell CSNET Technical Staff
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: 5 Jun 1985 00:37:36 EDT From: MILLS@USC-ISID.ARPA To: cak@PURDUE.ARPA, tcp-ip@SRI-NIC.ARPA Cc: MILLS@USC-ISID.ARPA Subject: Re: Speaking of 4.2 time programs
In response to the message sent 03 Jun 85 23:35:09 EST (Mon) from cak@Purdue.ARPA Chris, Mike O'Connor (oconnor@dcn9) installed a program on our Sun workstation which mumbles the DCNet protocols via our local Ethernet. Unfortunately, the Sun clock wanders all over the place and is unsuitable for locking to anything better than a windmill generator. I don't think you want the DCNet protocols, anyway, but some sort of similar protocol that operates over real Internet paths. That's not trivial, as a grok at RFC-889 should show. The fuzzies have a highly evolved tracking algorithm involving both linear and nonlinear filtering and estimation in order to achieve the claimed accuracies even on local nets. It would be a useful and positively fascinating exercise to adapt these algorithms to real Internet dynamics using UDP for coarse tracking and ICMP timestamps for fine synchronization. Someone out there should cop a Master's thesis for going after this one with hammer and tongs. Dave -------
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Jun-85 00:41:53 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Speaking of 4.2 time programs
From: Ron Natalie <ron@BRL.ARPA> Perhaps all the MILNET/ARPANET loading is coming from everybody trying to use DCN machines to set their clocks. -Ron
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Jun-85 01:13:01 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Fragging ARPAnet gateways
From: Ron Natalie <ron@BRL.ARPA> Yes, we realized this to. Our gateway had slight software modifications to cope with this. Fortunately the Ethernet has a little buffering on the boards (at least Interlan does), unfortunately some of the other strange devices we use here, did not. -Ron
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Jun-85 01:33:13 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Fragmentation
From: "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA> What will it take to define some protocol for establishing reasonable segment lengths? Comments that appear every month or so seem to cry out for some IP/ICMP do-dah by which two hosts can get a good guess of the fragmentation situation in between each other. For a start, any TCP/IP where TCP can't ask for the hardware MTU of the most likely routing to a given address should be taken out and shot. After that, perhaps some sort of IP option could be added to which any gateway involved would add its hardware MTU. An exchange of these at the beginning of a connection would improve the picture no end.
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Jun-85 02:14:36 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: ARPANET/MILNET performance statistics
From: Ron Natalie <ron@BRL.ARPA> Actually IMP packets are 1008 bits, IMP regular messages (what we know as packets) are from 96 to 8159 bits. Subtracting 96 bits off for the IMP leader leaves 8063 bits which is 1007 octets and 7 bits left over (a septet, I suppose). -Ron
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Jun-85 02:49:56 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Speaking of 4.2 time programs
From: MILLS@USC-ISID.ARPA In response to the message sent 03 Jun 85 23:35:09 EST (Mon) from cak@Purdue.ARPA Chris, Mike O'Connor (oconnor@dcn9) installed a program on our Sun workstation which mumbles the DCNet protocols via our local Ethernet. Unfortunately, the Sun clock wanders all over the place and is unsuitable for locking to anything better than a windmill generator. I don't think you want the DCNet protocols, anyway, but some sort of similar protocol that operates over real Internet paths. That's not trivial, as a grok at RFC-889 should show. The fuzzies have a highly evolved tracking algorithm involving both linear and nonlinear filtering and estimation in order to achieve the claimed accuracies even on local nets. It would be a useful and positively fascinating exercise to adapt these algorithms to real Internet dynamics using UDP for coarse tracking and ICMP timestamps for fine synchronization. Someone out there should cop a Master's thesis for going after this one with hammer and tongs. Dave -------
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Jun-85 03:46:22 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Fragmentation
From: Dennis Rockwell <drockwel@CSNET-SH.ARPA> A solution that I used in the later BBN 4.1 TCP/IP implementation was for the IP layer to pass to TCP the size of the largest fragment which went to make up the current IP packet. TCP then unilaterally restricted its segment size to twice the fragment size (less an appropriate fudge factor). This produces no tinygrams, although interfaces that can't handle back-to-back packets are still in trouble. Yes, it's a hack that violates level separation rules, but it made a big difference in practice. A useful facility that the SATNET folks have been good enough to provide are the IP echo hosts on the far side of satellite connections (goonhilly-echo for example). These switch the IP source and destination addresses and ship the packet out again. Since SATNET has the smallest MTU, the longest delay, and a penchant for dropping packets (this is not SATNET's fault; the speed mismatch between the ARPAnet and SATNET is ferocious and the gateway clogs), it's handy for testing TCP/IP implementations. It has been known to crash insufficiently bulletproofed software. Dennis Rockwell CSNET Technical Staff
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Jun-85 05:40:00 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Fragging ARPAnet gateways
From: Murray.pa@Xerox.ARPA There is another hack that's worth remembering if anybody is having troubles catching back-to-back packets: Slow down the transmitter. Some of our Ethernet drivers do that with only a few words of microcode. On the first (re)transmission, set the collision timer to 1ms. There are obviously variations and optimizations. The point is that it's trivial to implement and a small delay won't be noticed by most applications but it can be a lifesaver in a few critical cases. Credit where it's due dept: Ed Taft came up with this trick when our Alto based file servers couldn't keep up with our Dorados.
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: 5 Jun 1985 1146-PDT (Wednesday) From: Jeff Mogul <mogul@Navajo> To: MILLS@USC-ISID.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Speaking of 4.2 time programs
It would be a useful
and positively fascinating exercise to adapt these algorithms to real
Internet dynamics using UDP for coarse tracking and ICMP timestamps for
fine synchronization. Someone out there should cop a Master's thesis for
going after this one with hammer and tongs.
Someone already has copped a PhD thesis for devising some very
elegant algorithms to maintain distributed clocks even when
some clocks are lying. See Keith Marzullo's thesis "Maintaining
the Time in a Distributed System" (Stanford, 1983). His
implementation used Pup rather than IP protocols, but I think the
mapping is obvious. Keith's address is Marzullo.PA@Xerox.
Also see Gusella and Zatti, "TEMPO: Time Services for the
Berkeley Local Network", Berkeley EECS report # UCB/CSD 83/163,
which presents a simpler, although in my opinion inferior, algorithm
using UDP. I can't tell if they got a thesis out of this one or not.
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Jun-85 16:02:07 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Speaking of 4.2 time programs
From: Jeff Mogul <mogul@Navajo>
It would be a useful
and positively fascinating exercise to adapt these algorithms to real
Internet dynamics using UDP for coarse tracking and ICMP timestamps for
fine synchronization. Someone out there should cop a Master's thesis for
going after this one with hammer and tongs.
Someone already has copped a PhD thesis for devising some very
elegant algorithms to maintain distributed clocks even when
some clocks are lying. See Keith Marzullo's thesis "Maintaining
the Time in a Distributed System" (Stanford, 1983). His
implementation used Pup rather than IP protocols, but I think the
mapping is obvious. Keith's address is Marzullo.PA@Xerox.
Also see Gusella and Zatti, "TEMPO: Time Services for the
Berkeley Local Network", Berkeley EECS report # UCB/CSD 83/163,
which presents a simpler, although in my opinion inferior, algorithm
using UDP. I can't tell if they got a thesis out of this one or not.
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: 6 Jun 1985 11:05:48 EDT From: MILLS@USC-ISID.ARPA To: imagen!geof@SU-SHASTA.ARPA, tcp-ip@SRI-NIC.ARPA Cc: MILLS@USC-ISID.ARPA Subject: Re: Floods of tinygrams from telnet hosts
In response to the message sent Monday, 3 Jun 1985 11:23-PDT from imagen!geof@shasta Geof, What implementation are you referring to? John and I discussed this a long time ago. Subsequently, a send policy similar to this was introduced along with a companion ack policy in the fuzzball TCP, but so far as I know, not in any other implementation, although Berkeley claim to be doing that with 4.3bsd. The mechanism works as follows: 1. Arriving data from the user is queued temporarily at the transmitter. If the size of this queue is at least the MSS for the connection, it is packetized and sent immediately (subject to the usual window controls, of course). If not, the data are held until all previously sent data have been acked. Note that data arriving while a previously sent wadge is in flight simply pile up in the queue. 2. The receiver acks incoming data immediately if the amount of data passed on to the user (i.e. removed from reassembly buffers) since the last ack is at least the MSS for the connection. In addition, the receiver acks if some arbitrary time (here, about 500 milliseconds) has elapsed since new data arrived and no ack was sent. As reported previously, these policies dramatically improved the performance of TELNET over mismatched paths, while sustaining good performance of FTP. We have been using it for about six months now in the fuzzballs over the raunchiest of paths (would you believe Amateur packet-radio, which uses CSMA at 1200 bps at 145 MHz?). A major caution using these policies is the interaction between the send and ack policies with respect to the receiver ack delay, which increases the apparent delay for TELNET tinygrams. The delay is a major factor in improving performance with remote echo, since the acks normally piggyback on the echo segment, improving the apparent response time. However, in cases where no end-end traffic is wandering backwards over the path and segments less than the maximum are involved (e.g. many SMTP connections), a lot of dead air results. The issues need to be studied a bit more. Dave -------
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: Thursday, 6 Jun 1985 12:26-EDT From: bnsw@Mitre-Bedford To: tcp-ip@sri-nic Cc: bnsw@Mitre-Bedford Subject: ARPANET/LAN Accounting for UNIX TCP Applications
We are planning to hook up some LAN's to our ARPANET host using TCP/IP. We want to keep an account of the traffic (TELNET's, FTP's,TFTP's, and SMTP's) from the LAN hosts in using the ARPANET host. Has anyone written any accounting-type programs to gather usage stats for the hosts on a LAN that use/passthru an ARPANET host? Or, from a related viewpoint, to record ARPANET user statistics applicable for accounting from just the ARPANET host? We currently run UNIX 4.1bsd; we will soon be updating to ULTRIX (as a testbed 4.3bsd). Thank you for your time. Barbara Seeber-Wagner
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: Thu, 6-Jun-85 12:41:57 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Floods of tinygrams from telnet hosts
From: MILLS@USC-ISID.ARPA In response to the message sent Monday, 3 Jun 1985 11:23-PDT from imagen!geof@shasta Geof, What implementation are you referring to? John and I discussed this a long time ago. Subsequently, a send policy similar to this was introduced along with a companion ack policy in the fuzzball TCP, but so far as I know, not in any other implementation, although Berkeley claim to be doing that with 4.3bsd. The mechanism works as follows: 1. Arriving data from the user is queued temporarily at the transmitter. If the size of this queue is at least the MSS for the connection, it is packetized and sent immediately (subject to the usual window controls, of course). If not, the data are held until all previously sent data have been acked. Note that data arriving while a previously sent wadge is in flight simply pile up in the queue. 2. The receiver acks incoming data immediately if the amount of data passed on to the user (i.e. removed from reassembly buffers) since the last ack is at least the MSS for the connection. In addition, the receiver acks if some arbitrary time (here, about 500 milliseconds) has elapsed since new data arrived and no ack was sent. As reported previously, these policies dramatically improved the performance of TELNET over mismatched paths, while sustaining good performance of FTP. We have been using it for about six months now in the fuzzballs over the raunchiest of paths (would you believe Amateur packet-radio, which uses CSMA at 1200 bps at 145 MHz?). A major caution using these policies is the interaction between the send and ack policies with respect to the receiver ack delay, which increases the apparent delay for TELNET tinygrams. The delay is a major factor in improving performance with remote echo, since the acks normally piggyback on the echo segment, improving the apparent response time. However, in cases where no end-end traffic is wandering backwards over the path and segments less than the maximum are involved (e.g. many SMTP connections), a lot of dead air results. The issues need to be studied a bit more. Dave -------
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: Thu, 6-Jun-85 13:46:01 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: ARPANET/LAN Accounting for UNIX TCP Applications
From: bnsw@Mitre-Bedford We are planning to hook up some LAN's to our ARPANET host using TCP/IP. We want to keep an account of the traffic (TELNET's, FTP's,TFTP's, and SMTP's) from the LAN hosts in using the ARPANET host. Has anyone written any accounting-type programs to gather usage stats for the hosts on a LAN that use/passthru an ARPANET host? Or, from a related viewpoint, to record ARPANET user statistics applicable for accounting from just the ARPANET host? We currently run UNIX 4.1bsd; we will soon be updating to ULTRIX (as a testbed 4.3bsd). Thank you for your time. Barbara Seeber-Wagner
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: Thu 6 Jun 85 13:54:13-EDT From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA> To: tcp-ip@SRI-NIC.ARPA, local-nets@MIT-MC.ARPA Cc: JNC@MIT-XX.ARPA Subject: Interlan Ethernet card command codes
The Interlan UNIBUS/QBUS cards (NI1010 and NI2010) went through a variety of revs of firmware, and new commands were added at some points. I want a list of which commands were added at which levels of the firmware (since we have quite a mix of boards here). However, Interlan is unable (!!!) to provide me with this information. Does anyone out there have a list of which commands go with with which firmware revision levels? Noel -------
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: Thu, 6-Jun-85 15:08:06 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Interlan Ethernet card command codes
From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA> The Interlan UNIBUS/QBUS cards (NI1010 and NI2010) went through a variety of revs of firmware, and new commands were added at some points. I want a list of which commands were added at which levels of the firmware (since we have quite a mix of boards here). However, Interlan is unable (!!!) to provide me with this information. Does anyone out there have a list of which commands go with with which firmware revision levels? Noel -------
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: Fri, 7 Jun 85 01:36:52 edt From: bellcore!karn@Berkeley (Phil R. Karn) To: tcp-ip@sri-nic.ARPA Subject: Tinygrams on 4.2BSD
It is true that TCP on 4.2 effectively does a push every time the user process does a write() system call. It really has no choice since there are no semantics by which the user can indicate a push in the write call. But it doesn't have to be a problem IF programs call the standard I/O library instead. Stdio tries to fill its 1K buffers completely before calling the system, and the user is given a push-like subroutine fflush() for when it is really needed. The only real offenders (besides character-at-a-time Telnet) are those few programs that insist on using the bare I/O system calls directly to write small amounts of data; they should be taken out and shot. They give lousy performance even when a network isn't involved. I'm still looking forward to the new version which is rumored to include John Nagle's transmission algorithms. Phil
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: Fri, 7-Jun-85 02:36:39 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Tinygrams on 4.2BSD
From: bellcore!karn@BERKELEY (Phil R. Karn) It is true that TCP on 4.2 effectively does a push every time the user process does a write() system call. It really has no choice since there are no semantics by which the user can indicate a push in the write call. But it doesn't have to be a problem IF programs call the standard I/O library instead. Stdio tries to fill its 1K buffers completely before calling the system, and the user is given a push-like subroutine fflush() for when it is really needed. The only real offenders (besides character-at-a-time Telnet) are those few programs that insist on using the bare I/O system calls directly to write small amounts of data; they should be taken out and shot. They give lousy performance even when a network isn't involved. I'm still looking forward to the new version which is rumored to include John Nagle's transmission algorithms. Phil
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: 7 Jun 1985 12:41:26 EDT From: MILLS@USC-ISID.ARPA To: bellcore!karn@UCB-VAX.ARPA, tcp-ip@SRI-NIC.ARPA Cc: MILLS@USC-ISID.ARPA Subject: Re: Tinygrams on 4.2BSD
In response to the message sent Fri, 7 Jun 85 01:36:52 edt from bellcore!karn@Berkeley Phill, Please understand the "John Nagle algorithm" does not in itself represent a panacea, but only one of many detail-engineering issues involved in making TCP work well over widely ranging scenarios. That algorithm must be addressed in the context of a good ack policy. Experiments done here reveal the algorithm can result in very poor performance with some ack policies and can adversely affect performance in scenarios in the middle, so to speak, of the TELNET character-at-a-time and FTP spectrum. Simply stuffing the algorithm in the system blindly may exchange better performance at these extremes, which we ordinarily see first-hand, for poorer performance in the middle (e.g. mail), which chugs in the background slurping up resources we may not notice. Dave -------
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: Fri, 7-Jun-85 13:58:07 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Tinygrams on 4.2BSD
From: MILLS@USC-ISID.ARPA In response to the message sent Fri, 7 Jun 85 01:36:52 edt from bellcore!karn@Berkeley Phill, Please understand the "John Nagle algorithm" does not in itself represent a panacea, but only one of many detail-engineering issues involved in making TCP work well over widely ranging scenarios. That algorithm must be addressed in the context of a good ack policy. Experiments done here reveal the algorithm can result in very poor performance with some ack policies and can adversely affect performance in scenarios in the middle, so to speak, of the TELNET character-at-a-time and FTP spectrum. Simply stuffing the algorithm in the system blindly may exchange better performance at these extremes, which we ordinarily see first-hand, for poorer performance in the middle (e.g. mail), which chugs in the background slurping up resources we may not notice. Dave -------
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: 8 Jun 1985 03:26-EDT From: CERF@USC-ISI.ARPA To: mgardner@BBNCCY.ARPA Cc: MILLS@USC-ISID.ARPA, mills@DCN6.ARPA tcp-ip@SRI-NIC.ARPA Subject: Re: ARPANET/MILNET performance statistics
Marianne, I don't understand exactly what you are disagreeing with; I based my comments on the tables that Dave published. Are you disagreeing with the numbers he shows? It seemed to me that those tables reflected the ISI gateway bearing a consdierably larger amount of traffic than any other gateway by at least a factor of two (if memory serves) and that it dropped a higher percentage of packets. Please elaborate on your recent short note so it is clearer to me, at least, how you interpret Dave's tables. thanks, Vint
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: 8 Jun 1985 03:34-EDT From: CERF@USC-ISI.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: Computer Communications Review
Have you all seen the latest edition of the Computer Communications Review? There is an article which on the surface pans the ARPANET/DOD internet architecture. I think the author makes some points worth pondering about congestion - although I also think his model of how datagram networks functin is a bit off the mark. Some people think that a routing algorithm is run for every packet entering an IMP on the ARPANET. They don't seem to realize that the routing is done in the background and tables are produced for purposes of making routing decisions for each packet. So the overhead for routing a packet in the ARPANET is no more than it is for routing in a network which creates a set menu of routes in a table. The table look up is all it takes to make the routing decision, but the contents of the table, in ARPANET, are updated as a low-level background task. It doesn't consume much bandwidth (CPU or line). Does anyone agree/disagree with the author's other remarks? Is anyone considering a response? Vint
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: 8 Jun 1985 03:41-EDT From: CERF@USC-ISI.ARPA To: james@GYRE.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: ARPANET/MILNET performance statistics
Jim, unless things have changed dramatically when I wasn't looking, the IMP takes in up to 1008 bytes but breaks them into 1008 bit packets. The X.25 versions of the IMP take in 1024 bytes, so I suspect the single IMP packet is probably 1024 bits long in data field rather than 1008, for those IMPs. The IP datagram sizes therefore tell you whether you are dealing with single or multi-packet messages in the network. Any datagram larger than 126 bytes is therefore a multi-packet message and subject to the end/end protocol for multipacket messages. The 8 messages outstanding problem is usually exacerbated when there are a lot of small messages - short datagrams carrying interactive telnet traffic are the worst case. It's possible I wasn't very clear in what I was trying to say, but I do believe I'm correct that the IMP still breaks up messages larger than 126 bytes into multiple small packets of up to 1008 bits. I could be wrong about the 1008 bits, it could have gone up a little, but not much beyond 1024 bits, I bet. Vint
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: 8 Jun 1985 04:07-EDT From: CERF@USC-ISI.ARPA To: ron@BRL.ARPA Cc: mills@DCN6.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: ARPANET/MILNET performance statistics
Ron, Hmmmm. the average byte statistics don't tell us about maxima or distribution of 1822 message (see, I am being careful to distinguish 1822 MESSAGE from IMP PACKET!) sizes. Perhaps Marianne Gardner has available more detailed statistics which would tell us whether there is any significant amount of IP level fragmentation going on. Presumably one would not see the fragmenting going on at MILISI, for instance. Rather, it would occur at the gateway which interfaces the local area net to the ARPANET. If there were a significant number of 1536 byte IP messages being sent, these would fragment into two IP datagrams of roughly 1000 bytes and 536 bytes. [aside: I am no longer sure whether the present preferred gateway fragmentation algorithm at IP level is to make datagrams that just fit in the next net, in which case 1000 and 536 would be more or less right for ARPANET, neglecting headers and stuff; or whether the policy is to fragment to 576 maximum or to make all IP fragments uniform in size and less than or equal to 576 or less than or equal to the next net's maximum message size. Can a knowledgeable source please set me straight on that? ] It seems plain that something is causing the average IP datagram size to be larger at MILISI than at other gateways. Vint
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: Sat, 8-Jun-85 04:23:11 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: ARPANET/MILNET performance statistics
From: CERF@USC-ISI.ARPA Marianne, I don't understand exactly what you are disagreeing with; I based my comments on the tables that Dave published. Are you disagreeing with the numbers he shows? It seemed to me that those tables reflected the ISI gateway bearing a consdierably larger amount of traffic than any other gateway by at least a factor of two (if memory serves) and that it dropped a higher percentage of packets. Please elaborate on your recent short note so it is clearer to me, at least, how you interpret Dave's tables. thanks, Vint
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: Sat, 8-Jun-85 05:01:32 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Computer Communications Review
From: CERF@USC-ISI.ARPA Have you all seen the latest edition of the Computer Communications Review? There is an article which on the surface pans the ARPANET/DOD internet architecture. I think the author makes some points worth pondering about congestion - although I also think his model of how datagram networks functin is a bit off the mark. Some people think that a routing algorithm is run for every packet entering an IMP on the ARPANET. They don't seem to realize that the routing is done in the background and tables are produced for purposes of making routing decisions for each packet. So the overhead for routing a packet in the ARPANET is no more than it is for routing in a network which creates a set menu of routes in a table. The table look up is all it takes to make the routing decision, but the contents of the table, in ARPANET, are updated as a low-level background task. It doesn't consume much bandwidth (CPU or line). Does anyone agree/disagree with the author's other remarks? Is anyone considering a response? Vint
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: Sat, 8-Jun-85 05:54:01 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: ARPANET/MILNET performance statistics
From: CERF@USC-ISI.ARPA Jim, unless things have changed dramatically when I wasn't looking, the IMP takes in up to 1008 bytes but breaks them into 1008 bit packets. The X.25 versions of the IMP take in 1024 bytes, so I suspect the single IMP packet is probably 1024 bits long in data field rather than 1008, for those IMPs. The IP datagram sizes therefore tell you whether you are dealing with single or multi-packet messages in the network. Any datagram larger than 126 bytes is therefore a multi-packet message and subject to the end/end protocol for multipacket messages. The 8 messages outstanding problem is usually exacerbated when there are a lot of small messages - short datagrams carrying interactive telnet traffic are the worst case. It's possible I wasn't very clear in what I was trying to say, but I do believe I'm correct that the IMP still breaks up messages larger than 126 bytes into multiple small packets of up to 1008 bits. I could be wrong about the 1008 bits, it could have gone up a little, but not much beyond 1024 bits, I bet. Vint
-----------[000081][next][prev][last][first]---------------------------------------------------- Date: Sat, 8-Jun-85 06:28:33 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: ARPANET/MILNET performance statistics
From: CERF@USC-ISI.ARPA Ron, Hmmmm. the average byte statistics don't tell us about maxima or distribution of 1822 message (see, I am being careful to distinguish 1822 MESSAGE from IMP PACKET!) sizes. Perhaps Marianne Gardner has available more detailed statistics which would tell us whether there is any significant amount of IP level fragmentation going on. Presumably one would not see the fragmenting going on at MILISI, for instance. Rather, it would occur at the gateway which interfaces the local area net to the ARPANET. If there were a significant number of 1536 byte IP messages being sent, these would fragment into two IP datagrams of roughly 1000 bytes and 536 bytes. [aside: I am no longer sure whether the present preferred gateway fragmentation algorithm at IP level is to make datagrams that just fit in the next net, in which case 1000 and 536 would be more or less right for ARPANET, neglecting headers and stuff; or whether the policy is to fragment to 576 maximum or to make all IP fragments uniform in size and less than or equal to 576 or less than or equal to the next net's maximum message size. Can a knowledgeable source please set me straight on that? ] It seems plain that something is causing the average IP datagram size to be larger at MILISI than at other gateways. Vint
-----------[000082][next][prev][last][first]---------------------------------------------------- Date: Sat, 8 Jun 85 12:21:26 EDT From: Andrew Malis <malis@BBNCCS.ARPA> To: CERF@usc-isi.arpa Cc: james@gyre.arpa, tcp-ip@sri-nic.arpa, malis@BBNCCS.ARPA Subject: Re: ARPANET/MILNET performance statistics
Vint, You are completely correct about 1822 messages greater than 126 bytes being broken up into packets up to 126 bytes long each, and that the IMP end-to-end protocol imposes greater overhead (destination IMP buffer space preallocation, to be precise) for multipacket messages. For X.25 traffic, the IMP uses 134-byte packets, so that a full-sized X.25 message (1024 bytes + some overhead) still fits in 8 packets. The same multipacket overhead applies. Andy Malis
-----------[000083][next][prev][last][first]---------------------------------------------------- Date: Sat, 8-Jun-85 15:08:17 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: ARPANET/MILNET performance statistics
From: Andrew Malis <malis@BBNCCS.ARPA> Vint, You are completely correct about 1822 messages greater than 126 bytes being broken up into packets up to 126 bytes long each, and that the IMP end-to-end protocol imposes greater overhead (destination IMP buffer space preallocation, to be precise) for multipacket messages. For X.25 traffic, the IMP uses 134-byte packets, so that a full-sized X.25 message (1024 bytes + some overhead) still fits in 8 packets. The same multipacket overhead applies. Andy Malis
-----------[000084][next][prev][last][first]---------------------------------------------------- Date: 08 Jun 85 17:29:23 EDT (Sat) From: Mike Brescia <brescia@bbnccv> To: tcp-ip@nic Cc: brescia@bbnccv Subject: Re: ARPANET/MILNET performance statistics
Vint, Ron, Dave, Marianne, &al. The statistics collected from the BBN gateways include only total packet counts and total byte counts. The average reported is (you guessed it) byte-count divided by packet count. There's no facility for histograms, maxima, standard deviation, or other interesting statistics. The gateways currently fragment in the manner you recall, Vint, with the first fragment(s) being as large as possible, and the last one containing the leftovers. The idea of splitting a datagram as close to the half-way (or 1/N if N fragments are needed) was not deemed useful for the arpanet, because the end-to-end overhead is the same for a 130 byte or 576 byte packet as for a 1000 byte packet. The best policy for the arpanet was to get the packets large as possible. My intuition about MILISI carrying larger packets than others is that ISI has large hosts (TOPS20) on both sides of the mil-arpa divide, and they may do lots of file transfers (ftp big packets) or screen outputs (telnet big packets). One of the ISI wizards may be able to shoot holes in that speculation... Good hunting, Mike
-----------[000085][next][prev][last][first]---------------------------------------------------- Date: Sat, 8-Jun-85 18:50:09 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: ARPANET/MILNET performance statistics
From: Mike Brescia <brescia@bbnccv> Vint, Ron, Dave, Marianne, &al. The statistics collected from the BBN gateways include only total packet counts and total byte counts. The average reported is (you guessed it) byte-count divided by packet count. There's no facility for histograms, maxima, standard deviation, or other interesting statistics. The gateways currently fragment in the manner you recall, Vint, with the first fragment(s) being as large as possible, and the last one containing the leftovers. The idea of splitting a datagram as close to the half-way (or 1/N if N fragments are needed) was not deemed useful for the arpanet, because the end-to-end overhead is the same for a 130 byte or 576 byte packet as for a 1000 byte packet. The best policy for the arpanet was to get the packets large as possible. My intuition about MILISI carrying larger packets than others is that ISI has large hosts (TOPS20) on both sides of the mil-arpa divide, and they may do lots of file transfers (ftp big packets) or screen outputs (telnet big packets). One of the ISI wizards may be able to shoot holes in that speculation... Good hunting, Mike
-----------[000086][next][prev][last][first]---------------------------------------------------- Date: 9-Jun-85 23:01-EDT From: Joseph Szep <ccjts%BOSTONU.bitnet@WISCVM.ARPA> To: tcp-ip@Berkeley Subject: Please remove me....
-----
from the tcp-ip mailing list.
Thanx Joe Szep
-----
-----------[000087][next][prev][last][first]---------------------------------------------------- Date: Mon, 10-Jun-85 00:31:56 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Please remove me....
From: Joseph Szep <ccjts%BOSTONU.bitnet@WISCVM.ARPA>
-----
from the tcp-ip mailing list.
Thanx Joe Szep
-----
-----------[000088][next][prev][last][first]---------------------------------------------------- Date: 10 Jun 1985 08:48-PDT From: Joel Goldberger <JGoldberger@USC-ISIB.ARPA> To: Brescia@BBNCCV.ARPA Cc: TCP-IP@SRI-NIC.ARPA Subject: Big packets at ISI
We confess ! We do in fact do a far amount of FTPing and especially Telnetting among our machines on both sides of the diivide. - Joel Goldberger -
-----------[000089][next][prev][last][first]---------------------------------------------------- Date: Mon 10 Jun 85 13:21:28-MDT From: Mark Crispin <MRC@SIMTEL20.ARPA> To: JGoldberger@USC-ISIB.ARPA Cc: Brescia@BBNCCV.ARPA, TCP-IP@SRI-NIC.ARPA Subject: Re: Big packets at ISI
Considering the important position of the MILISI gateway, perhaps it might make sense to invest in some form of networking technology to allow ISI to do internal data transfers without using MILISI (either an LAN or a private ISI-only gateway)? ISI's internal needs are obviously sufficiently great to make this sort of thing desirable. -------
-----------[000090][next][prev][last][first]---------------------------------------------------- Date: Mon, 10-Jun-85 12:51:41 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Big packets at ISI
From: Joel Goldberger <JGoldberger@USC-ISIB.ARPA> We confess ! We do in fact do a far amount of FTPing and especially Telnetting among our machines on both sides of the diivide. - Joel Goldberger -
-----------[000091][next][prev][last][first]---------------------------------------------------- Date: 10 Jun 85 15:55:48 EST (Mon) From: Christopher A Kent <cak@Purdue.ARPA> To: tcp-ip@sri-nic.arpa Subject: 4.2 date setting program
Hi, Bill Nesheim retrieved a copy of my UDP-based time setting programs for 4.2 and found a lurking bug -- if the client didn't succeed in reaching any of the servers, the system time would be set back to the time at which the program started (at least 10 seconds ago.) I've fixed this and placed a new copy in purdue-merlin:pub/dated.flar (via anonymous FTP.) Cheers, chris ----------
-----------[000092][next][prev][last][first]---------------------------------------------------- Date: Mon, 10 Jun 85 15:40:53 EDT From: "Paul D. Amer" <amer@UDel-Dewey.ARPA> To: tcp-ip@SRI-NIC.ARPA Cc: bnsw@MITRE-BEDFORD.ARPA, mizell@usc-isi.ARPA, amer@UDel-Dewey.ARPA Subject: arpanet/lan accounting for unix tcp applications
Regarding your question about if anyone has written any accounting-type programs to gather usage stats for the hosts on a lan: At Delaware, we have a project sponsored by the Office of Naval Research to perform a characterization of LAN traffic. Over the past year, we have developed a system that monitors the ethernet, saves one minute summaries (snapshots) of traffic on a disk, and analyzes the traffic offline. Our analysis includes a characterization of the higher level protocols used, the amount of intra vs. interLAN traffic, a summary of packet interarrival times, and lots more. We are currently finishing a characterization of 2 months worth of LAN traffic involving approximately 80 million packets. Our results will be written up in a report available hopefully by the end of the summer.
-----------[000093][next][prev][last][first]---------------------------------------------------- Date: Mon, 10-Jun-85 18:51:48 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Big packets at ISI
From: Mark Crispin <MRC@SIMTEL20.ARPA> Considering the important position of the MILISI gateway, perhaps it might make sense to invest in some form of networking technology to allow ISI to do internal data transfers without using MILISI (either an LAN or a private ISI-only gateway)? ISI's internal needs are obviously sufficiently great to make this sort of thing desirable. -------
-----------[000094][next][prev][last][first]---------------------------------------------------- Date: Mon, 10-Jun-85 19:38:04 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: 4.2 date setting program
From: Christopher A Kent <cak@Purdue.ARPA> Hi, Bill Nesheim retrieved a copy of my UDP-based time setting programs for 4.2 and found a lurking bug -- if the client didn't succeed in reaching any of the servers, the system time would be set back to the time at which the program started (at least 10 seconds ago.) I've fixed this and placed a new copy in purdue-merlin:pub/dated.flar (via anonymous FTP.) Cheers, chris ----------
-----------[000095][next][prev][last][first]---------------------------------------------------- Date: Mon, 10-Jun-85 20:07:08 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: arpanet/lan accounting for unix tcp applications
From: "Paul D. Amer" <amer@UDel-Dewey.ARPA> Regarding your question about if anyone has written any accounting-type programs to gather usage stats for the hosts on a lan: At Delaware, we have a project sponsored by the Office of Naval Research to perform a characterization of LAN traffic. Over the past year, we have developed a system that monitors the ethernet, saves one minute summaries (snapshots) of traffic on a disk, and analyzes the traffic offline. Our analysis includes a characterization of the higher level protocols used, the amount of intra vs. interLAN traffic, a summary of packet interarrival times, and lots more. We are currently finishing a characterization of 2 months worth of LAN traffic involving approximately 80 million packets. Our results will be written up in a report available hopefully by the end of the summer.
-----------[000096][next][prev][last][first]---------------------------------------------------- Date: 11 Jun 85 11:59 PDT From: Tom Perrine <tom@LOGICON.ARPA> To: tcp-ip@sri-nic Cc: Tom Perrine <tom@logicon> Subject: Passage TCP/IP for UNIX Sys V
According to "The DEC Professional", June '85, pp. 172-173, Uniq Digital Technologies has produced a full TCP/IP, SMTP, FTP and Telnet for UNIX Sys V on VAXen. Does anyone have any other info (anyone have any firsthand experience with this beast) ? Tom Perrine Logicon - Operating Systems Division
-----------[000097][next][prev][last][first]---------------------------------------------------- Date: Tue, 11-Jun-85 15:44:40 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Passage TCP/IP for UNIX Sys V
From: Tom Perrine <tom@LOGICON.ARPA> According to "The DEC Professional", June '85, pp. 172-173, Uniq Digital Technologies has produced a full TCP/IP, SMTP, FTP and Telnet for UNIX Sys V on VAXen. Does anyone have any other info (anyone have any firsthand experience with this beast) ? Tom Perrine Logicon - Operating Systems Division
-----------[000098][next][prev][last]