geof@apolling.UUCP.UUCP (03/25/87)
> In article <8703220422.AA13307@buita.bu.edu> jsol@buit1.bu.EDU writes: > > From: Scott Earley <EARLEY@BITNIC> > > > > ... Tables > > for all sites on the Ohio side of the PSU-Ohio link will be put > > on tape and mailed overnight to a pre-appointed individual who > > will reintroduce them into the network from there. > > ... > > > >That's right. Mag tape. > > > >--Daemon > > Never underestimate the bandwidth of a station wagon full of magtapes! > Well, we can't resist this, can we. Back of the envelope calculations for a station wagon full of bits transmitted from the east coast to the west coast follow. Apologies for any naivitee about magtapes -- I don't use them often and never learned all the sordid details. Station wagon: 5' X 5' X 3' trunk Transit time: 4 days = 345 600 s (might add a day on each side to copy the data to & from tape) Data: 1 magtape, 12"X1" reel, 1000' of tape, 9600 bpi, 9 tracks => 12*1000*9600*9 = 129.6 E 6 bits 5*5*36 = 875 magtapes in trunk => 875*129.6 = 113.4 E 9 bits Throughput: 113.4e9 b / 345600 s = 328,125 b/s Hmm.... better than the arpanet.... how much does a station wagon cost these days, anyway... Corrections welcome (they might as well be, I'm sure there will be some!), - Geof
CERF@A.ISI.EDU.UUCP (03/25/87)
Never confuse bandwidth with timeliness and utility. For example, take the highest density storage medium you can think of - say the 10**10 bits per square inch optical storage disks, put a stack of them in a knapsack. Walk from east coast to west coast: The 14" disk has about pi*(5)**2 sq inches and you can put about 100 of these disks into the sack (at 1/2 pound each that would be a reasonable 50 lbs). At an average speed of 3 mph for 10 hours a day, it would take 100 days or 100*86,400 seconds. So you have roughly: (22/7)*25*10**10 bits per disk = 7.86 * 10**10 bits per disk 100 disks = 7.8 * 10**12 bits At 3 mph for 10 hrs/day it takes 100 days to go 3000 miles. 100 days at 86,400 seconds/24 hr day = 8.6 * 10**6 seconds So the coast to coast data rate for Johnny Appleseed is: 7.8/8.6 * 10**5 = about .9 * 10**5 = 90 kb/s which is about double the bandwidth you can get out of an unloaded ARPANET with today's 56 kb/s backbone. But few applications can deal with 100 day transmisstion/propagation delay. If people want to pursue this line of reasoning, I suggest that we invent a new unit of transmission: Appleseeds which are measured in Megabytes per Fortnight. Since a Megabyte per Fortnight is about a Megabyte in 14 days which works out to close to 1 byte per second, it is easy to see that the optical disk/Adidas method yields roughly 90 kiloAppleseeds. Vint
CERF@A.ISI.EDU.UUCP (03/25/87)
OOPS. The Appleseed is 1 MB/1.2 Msec = 8 Mb/1.2 Msec = 6.7 bps So 90 Kbps is about 13.5 K Appleseeds Vint
hinden@CCV.BBN.COM.UUCP (03/25/87)
Geof, Just think of the bandwidth of a 747 full of magtapes! Bob
ahill@CC7.BBN.COM.UUCP (03/25/87)
Back in the early 70's when the ARPANET was a little zippier than it is today, SDAC tried to send full 1600bpi 9 track tape contents from Virginia to UCLA using a very highly tuned block transfer FTP that got roughly 18KB continuous across the network. We needed to transfer six tapes a day and rapidly learned (the hard way) that the US Snail could outperform the network in bandwidth and cost. I don't suggest that the network is not efficient or useful but it easy to misuse particularly with bulk data transfers. Alan
PERRY@VAX.DARPA.MIL.UUCP (03/26/87)
Geof, suggest you use 2400 feet for a standard mag tape. At about 40 Mbytes per tape or 320 E 6 bits instead of 129.6 E 6 bits. Gives you roughly a factor of 3 better thru put. Last time I checked a station wagon cost about a fouth the cost of a butterfly gateway. Or about four months of 56 kbit/s cross country line from ATT. dennis -------
karn@flash.bellcore.COM.UUCP (03/26/87)
You really should update this old idea to use more up-to-date technologies. To wit: What is the bandwidth of a B-747 (DC-10, L-1011, A-300) loaded with Compact Discs or CD Roms? (To be fair, we should compare this to a fiber link covering the same path.) With fiber, the economies of scale in transmission are enormous. However, the ARPANET has been around a long time. Its internal routing algorithms were built to squeeze the most out of the slow and expensive leased lines available in 1969. Its internal protocols and congestion control techniques were designed to squeeze the most out of the expensive, memory-poor computers available in 1969. It was an excellent computer network -- for 1969. Unfortunately, much of this simply can't scale in its present form to where it can effectively utilize the new economies of scale in transmission. Making decisions about the future of networking by comparing the "operating costs" of ARPANET and MILNET to GTE Telenet is dangerous. For one thing, Telenet was also built on 1970's technology and protocols. Also, its users pay *real money* depending on how much traffic they send. Unlike the ARPANET/MILNET, Telenet's primary use is as a nationwide "remote terminal concentrator", with the vast majority of users dialing into X.3/28/29 PADs with dumb terminals and connecting to timesharing hosts. Their only alternative is to dial a direct long distance call using AT&T or MCI or whatever, and Telenet is well aware of this; they price their service accordingly. Anyone who tries to use it for computer-to-computer internetworking (as we do through CSNET/X.25NET) finds out VERY quickly just how expensive this can be. The circuit-switched mentality is deeply ingrained in Telenet's internal design; at least with the DDN, X.25 is kept on the edges, making it at least theoretically possible to escape its braindamage. In deciding where to spend future bucks, I think it would make a lot more sense to look at newer technologies. Because the transmission guys have leapfrogged so far over the switching guys, a radical change in mindset is in order. It simply doesn't pay anymore to worry about efficient PSN buffer utilization, 100% delivery reliability, packet header overhead, finding the most optimal routes, or load splitting if doing so takes so much CPU time that you can't drive fast links at full speed. At present, only link-level bridges like the Vitalink Translan III seem able to switch packets quickly enough to drive a T-1 link to 100% utilization on small packets; if somebody can do this with an X.25 switch or IP gateway I would like to know about it. Phil
Mills@UDEL.EDU.UUCP (03/26/87)
Geof, Recalculate using compact-disk ROMs and Federal Express. The ARPAfolks calculated back in the late sixties that it would be cheaper to send a pagefull of text via the ARPANET than as a first-class letter. On the other hand, for bulk data larger than a megabit, the cheapest way was an airmailed magtape. Maybe one of the original Buzzards might certify and maybe update my recollections. Dave
Mills@UDEL.EDU.UUCP (03/26/87)
Vint, Yeah, that's the kind of model I was fishing for. But, now you have to consider the energy input to the system, which depends on the weight of the knapsack. Ordinarily, we don't worry about that in the ARPANET, since the total energy input (watts and bucks?) is first-order independent of the bits carried. Therefore, I submit a more relevant measure might be microjoules/appleseed. At least Johnny left some trees in his wake. A long time ago while working my way through school as a disk jockey, I tossed off a calculation on the total length of the record grooves played throughout the day (about 100 miles). The station manager liked it so much he asked me to work the idea into a promo spot, which I did. The idea caught on and was copied by other local stations as well. It seems the issues can often be exposed effectively by outrageous changes in the assumptions and then working through the logic anyway to see if it all fits. Okay, I promise to shut up. Dave
GROSSMAN@SIERRA.STANFORD.EDU.UUCP (03/26/87)
I did a few calculations of the bandwidth of Wagonnet, and heres what I came up with: The most readily available magtape technology happens to be 2400' reels. These have a common maximum density of 6250 bytes/inch. This results in a value of 6250*12 = 75000 bytes/foot, and therefore we get 75000*2400*8 = 1.44e9 bits/tape. Now, your average 2400 foot reel is about 10.75 inches in diameter by 1 inch high, so (squaring off the corners) you get a volume of 115.6 cu inches/tape, and therefore you can get 12^3/115.6 = 14.98 tapes per cubic foot. This amounts to (rounding up to whole magtapes) 15*1.44e9= 21.6e9 bits/cu ft. Now, your typical station wagon holds anywhere from 30 to 65 cubic feet of stuff. I'll presume that this station wagon is large, since it has to deal with Bitnet. Therefore it holds 65*21.6e9= 1.404e12 bits/station wagon. Now, at a rate of 55 mph (I don't want to break the law), this station wagon can get across the country in 3000/55 * 3600 +10% = 216000 seconds. The 10% is for dealing with changing drivers, food amd gas stops, etc.... This results in a baud rate of 1.404e12/216000 = 6.5e6 bits/sec. This is comparable to typical Ethernet thoughput with a good controller and few collisions. Of course, this network has the advantage that congestion doesn't make it lose data. It just gets there kinda slowly. However, the RTTs are rather long (on the order of 216000*2= 5 days. But despair not, there's some hope! If congress raises the speed limit to 65mph, then the typical RTT will be reduced to a mere 3.8 days. You could probably convince congress that it would be in the best interests of national defense to do this! Note that a speed limit of 216 million mph would result in a much more reasonable RTT on the order of .1 seconds! Stu Grossman -------
gross@GATEWAY.MITRE.ORG.UUCP (03/26/87)
Bob, You've been scooped. There has already been a proposal involving a 747. Naturally, it's called.... Jumbo-net. Phill
gds@SPAM.ISTC.SRI.COM.UUCP (03/27/87)
Instead of using wagons, why not contract a moving company (e.g. Allied, NorthAmerican) to do this? We might be able to get cheaper rates with the moving companies than to contract out a set of drivers and their wagons. I would imagine the lifetimes of these wagons would be small relative to the lifetimes of moving vans (not many cars last through extensive heavy moving). Plus, the routes the van lines use are already set up, and probably parallel the cross-country trunks. We will be able to get much better bandwidth (I'm assuming the capacity of a moving van to be at least 10 times that of a station wagon), less overhead involved in switching drivers (they make a living out of doing this so they know how to switch with minimum delay), more bits/driver (they are trained so they need less sleep). Let's use planes to fly the transcontinental links. They're not quite so good for transmission within a continent (case in point: you can't land one at an imp :-). --gregbo
rpw3@amdcad.UUCP.UUCP (03/27/87)
If you use 6250 fci, 2400' tape, and long records, you can get
about 80% use of the tape, or 144 Mbytes. Adds ANOTHER factor
of 3, so the original posting was about an order of magnitude low.
Incidently, given the volume of stuff that is seen on USENET (over
1 Mbyte/day, now), and the size of some of the phone bills, the
typical transport delay, and the fact that priority (2-day) mail
is fairly cheap, mailed magtapes (small ones) or floppies really
SHOULD be considered as a way of distributing netnews!
Rob Warnock
Consultant
UUCP: {amdcad,fortune,sun,attmail}!redwood!rpw3
ATT: attmail!rpw3
DDD: (415)572-2607
USPS: 627 26th Ave, San Mateo, CA 94403ms6b#@ANDREW.CMU.EDU.UUCP (03/27/87)
In their classic article published in 1970*, Roberts and Wessler compare the cost per megabit for a variety of transmission media including mailing an IBM tape. (Which was lower by an order of magnitude than any other medium.) *"Computer network development of achive resource sharing," Proceedings of the AFIPS Spring Joint Computer Conference, vol 36, May 5-7, 1970 pp. 543-549.
mckee@MITRE.ARPA.UUCP (03/27/87)
This note is from Steve Silverman "m15368%mwvm@mitre.arpa"
He's not on the tcp-ip mailing list. We have some kind of weird
lash-up here at MITRE with a curious lack of transitivity:
Steve can send to me; you and I can send to Steve, but Steve can't
send to you. Anyway .....
________________________________
To: KARN%FLASH.BELLCORE.COM
From: Steve Silverman
Subject: future networks
I just received a copy of your message of 3/25 on future nets. I agree
with you and the current direction of network evolution as developing
in T1D1 and SG XVIII supports what you said.
Frame relay uses LAPD on each end with the transit switches just relaying
the frames. This allows very low transit delay and high capacity switches.
AT&T is supposedly testing a megapacket/second switch. The Bellcore
contingent at T1D1 is fairly active in this. Do you know Kaj Tesink?
(I don't know how to spell his name but I think he works for Joan LaBanca.)
(Kaj rhymes with sky.)
Frame Relay is a complete violation of the OSI model but nobody wants to
admit it. In my view, the fiber-optic explosion has invalidated the
details of the OSI model. The FO error rate is low enough that it no longer
pays to do error checking and retransmission on a link by link basis.
I think that the deployment of ISDN equipment in the 88-91 timeframe will
will be a major shock to the current networking world. Running layer 2
end to end will make layer 3 redundant. (Except we are moving some of the
layer 3 functionality into Q.931 (the call control protocol).)
Most of the data networking world is oblivious to ISDN. I still hear
statements that it won't happen until the next century. I think that
by 1990, ISDN will be in serious use in many places.
Steve Silverman hinden@CCV.BBN.COM.UUCP (03/28/87)
Stu, A collision in Wagonnet is, of course, much more serious than on an Ethernet. Retransmissions might be more difficult to arrange. You do have all of your "bits" in one "Wagon" :-). Bob
MAB@CORNELLC.BITNET.UUCP (03/28/87)
Stu, in comparing Wagonnet with Ethernet, you mentioned that for Wagonnet, congestion is not as much of a problem. What you neglected to mention, though, is that for our now well-discussed station wagon, collisions are much more serious! (Sorry, couldn't resist. :-) Mark Bodenstein
bzs@BU-CS.BU.EDU.UUCP (03/28/87)
While at Harvard in the mid-70's we in fact used a similar method of transferring things. We had a research group in Ohio and occasionally the (semi-portable home-brewed) computer broke down. We simply ran to the airport with a spare, bought it a seat on the next flight and had someone meet it at the airport gate at the other end (a similar method is often used to transfer children around the country.) We did the same sort of thing with (large) boxes of floppies occasionally to start up data analysis, it worked well enough (plus or minus traffic jams at Logan Airport.) The broken computer was returned similarly. The cost was very reasonable compared to other options, we were under heavy time pressure to keep the data collection rolling. While we're on the subject of using planes, why not rockets laden with CDs and launched in parabolic arcs, much faster. We can refer to it as the Strategic Data Initiative, perhaps a proposal is in order. -Barry Shein, Boston University
sy.Ken@CU20B.COLUMBIA.EDU.UUCP (03/30/87)
Stu, in comparing Wagonnet with Ethernet, you mentioned that for Wagonnet, congestion is not as much of a problem. What you neglected to mention, though, is that for our now well-discussed station wagon, collisions are much more serious! (Sorry, couldn't resist. :-) I would also hope that the driver would not "back off and retry"... :-) -------
ron@BRL.ARPA.UUCP (03/30/87)
A friend of mine who formerly worked at CCI implemented their network by running around the building with an armful of floppy disks...coined "Adidas Net" -Ron
martillo@ATHENA.MIT.EDU.UUCP (03/30/87)
I confess to not having thought about it too much, but my impression is frame relay simply permits the passage of level 2 packets on the basis of level 2 address through the switch to some place in the phone network where full level 2 processing can be handled. This means that the switch can basically concentrate on tdm switching problems while the level 2 termination point can concentrate statistical muxing switching problems. Such a division makes sense as a way to optimise CSC switch or packet switch performance. In the asynchronous world LAPD could per passed on a 64 KBPS unrestricted data circuit to a terminal concentrator and each LAPD virtual level 2 could correspond to an asynchronous terminal. While I consider asynchronous terminal concentrators a backward-looking technology, in the business world lots of firm want such devices. Obviously this is not an OSI application, but the separation of the problem into a physical channel, multiple virtual level 2s, and a flow control layer on top of this has clearly been influenced by concepts of layering, and LAPD terminal multiplexing seems more sensible than the PAD protocols. Yaqim Martillo
mckee@MITRE.ARPA.UUCP (03/30/87)
Phil asked, "What is the bandwidth of a 747 ..."
I talked to the Boeing folks here in DC. A B747-200F
(cargo config.) has: gross take-off wt. 416 tons
operating wt. 171
the difference being fuel and cargo wt. 245
Allowing 45 tons of fuel for 6 hours enroute plus reserve
leaves 200 tons of compact disks. According to Cerf,
100 disks equals 50 pounds equals 7.8*10**12 bits; therefore,
multiplying by 8,000,
800,000 disks - 200 tons - 6.2*10**16 bits
dividing by (6*3600) 21,600 seconds equals 2.9*10**12 bps.martillo@ATHENA.MIT.EDU.UUCP (03/31/87)
Is frame-forwarding really more of a violation of the OSI model than an ethernet bridge. A frame-forwarding switch does not strike me as a great deal different in concept or functionality than an ethernet bridge. Yakim Martillo
CERF@A.ISI.EDU.UUCP (04/02/87)
Stu, one little observation. A single collision in your tapemobile would do rather more damage than the typical collision on an ethernet. Shows why putting all your bits in one packet isn't a good policy... Vint
CERF@A.ISI.EDU.UUCP (04/02/87)
Bob, just came across your message about the station wagon full of bits - amazing! You and I had nearly the identical reaction as you'll see when you read TCP-IP and catch my message [sometimes I think I should read my mail backwards...]. Vint
CERF@A.ISI.EDU.UUCP (04/02/87)
One of the important features of X.25 and other packet-oriented services (and of DOD TCP/IP or ISO TP/IP, etc.) is the ability to support many simultaneous virtual connections. The ISDN facilities will not replace that functionality if level 3 is erased and only level 2 remains and only supports a single connection at a time. ISDN does provide for a packet mode interface which is basically a level 3 construct. I do not see that the pt-pt 64 kb/s service from ISDN will render the multi-connection modes of operation useless. Vint