Return-Path: Received: by massis.lcs.mit.edu (8.7.4/NSCS-1.0S) id OAA29136; Wed, 28 Aug 1996 14:10:05 -0400 (EDT) Date: Wed, 28 Aug 1996 14:10:05 -0400 (EDT) From: ptownson@massis.lcs.mit.edu (TELECOM Digest Editor) Message-Id: <199608281810.OAA29136@massis.lcs.mit.edu> To: ptownson@massis.lcs.mit.edu Subject: TELECOM Digest V16 #447 TELECOM Digest Wed, 28 Aug 96 14:10:00 EDT Volume 16 : Issue 447 Inside This Issue: Editor: Patrick A. Townson Re: Why is the Internet So Slow? (Peter Morgan) Re: Why is the Internet So Slow? (Clark R. Wilkins) Re: Why is the Internet So Slow? (Peter Morgan) Re: Why is the Internet So Slow? (David Richards) Re: Why is the Internet So Slow? (Rishab Aiyer Ghosh) Re: Why is the Internet So Slow? (John B. Hines) Re: Why is the Internet So Slow? (John R. Levine) Re: Why is the Internet So Slow? (Garrett Wollman) Re: Why is the Internet So Slow? (James E. Bellaire) Re: Is the Internet Slow? (James E. Bellaire) Re: Will Full Number Portability Occur? (Roger Wells) Re: Will Full Number Portability Occur? (Clark R. Wilkins) Re: Will Full Number Portability Occur? (John R. Levine) Re: Correction: Microsoft and the Apple II (David E.A. Wilson) ---------------------------------------------------------------------- From: P Morgan Subject: Re: Why is the Internet So Slow? Date: Wed, 28 Aug 1996 07:29:04 +0100 In message PAT wrote: > So I took Bill Pfieffer's advice and 'moved to the Web' with the > Archives although I don't really know what to think about it at this > point in time. According to him, if one is not on the Web these days, > one might as well not be on the net at all. It does seem that more and more Gopher servers are being shut down, or just not updated, as many sites feel and find that web usage has become the highest single cause of traffic. How useful the content of that traffic is, however, I hesitate to comment. > Some people write me to say how poorly the web page is put together, From your later comments it appears they _want_ graphics and so on ... To be honest, the small portions I've seen so far are great, and "well done" should be the comment, not criticism :-< > very long time to load. I just don't know what I am going to do with > the Telecom web page at this point in time. PAT] I've just added a few links to your pages. Admittedly mine is far from the "top 5%" of sites, but readers are invited to take a look ... http://www.ultranet.com/~pgm/ Keep up the good work, Pat. I'm in favour of minimalist web pages! (Although I must admit I started to do a "my-trips" set of pages and the first had a piece of the globe with marks for the few places world-wide where I've travelled -- it was a pain trying to show the west coast, Europe and get some suggestion of the Far East on one view Oh.. just thought how I should have done it ... with a great circle from LA to Singapore, but the "long way" round :-) ------------------------------ Date: Wed, 28 Aug 1996 10:46:50 -0500 From: clarkw@accesscomm.net (Clark R. Wilkins) Subject: Re: Why is the Internet So Slow? Mark Friedman <71534.332@CompuServe.COM> wrote: > I am performing some research and am interested in hearing from anyone > with an interesting theory of why Internet access is so slow? I found an article in the current issue of Wired quite informative about this problem. I do not have the issue here at the house. The cover has the "Tired/Wired 100" on it. The article is in the Electrosphere section and is, in the usual Wired mode, quite informative without being boring. Clark R. Wilkins * President, J.D.I. Solutions, Inc. 713-974-2434 (f) 713-974-5248 ------------------------------ From: P Morgan Subject: Re: Why is the Internet So Slow? Date: Wed, 28 Aug 1996 07:37:22 +0100 In message johnd@mail.ic.net (John Dreystadt) writes: > protocol to occur. It would be much less burden on the net to do > "server side includes" where the server read the file and included all > of the graphic images. There are issues about caching that my simple > description has entirely ignored but I hope you can see my point. Please spare us from this being forced on us. Sure it reduces the number of connections, but I'd download very few pages if it was "the norm". I think it is Hong Kong's Port Authority which has many dozen graphic images (representing Chinese characters) and at the end was the "get your booklet about the Port Authority here" text, in English. We switched off image loading and zzziiiippp we had the required link and could do what we needed. We'd still be waiting if they'd put SSI into force. Peter ------------------------------ From: dr@ripco.com (David Richards) Subject: Re: Why is the Internet So Slow? Organization: Ripco Internet BBS Chicago Date: Tue, 27 Aug 1996 22:57:26 GMT Not to be rude, but Mr. Dreystatd does not know what he is talking about. HTTP is based on TCP/IP, not UDP. 'Server-Side-Include' has nothing to do with how graphics are loaded by the browser. > While there is much value in the overall message, there are some > technical errors in this paragraph. The HTTP protocol does not use > TCP/IP but instead uses the connectionless cousin, UDP/IP. I am not > entirely certain what the references are to "connection" in this > paragraph but I suspect "transaction" is the correct word. I am not > sure of the number of round trips a single transaction takes in the > HTTP protocol but three seems reasonable. HTTP uses TCP. The client initiates a connection, sends a series of HTTP headers beginning with a request for a file, then a single blank line. The server responds with a series of headers starting with a result code, then a blank line, then the document content, if any. > A missing issue with the standard HTTP protocol and the interface > between the server and the browser is the handling of multiple > files. A standard web page often has many individual graphic > files. The standard model for HTTP involves what is best described as > "browser side includes". The main file for the web page is brought > over to the browser and the browser parses the file. Each graphic file > within the web page causes an individual file transfer using the HTTP > protocol to occur. It would be much less burden on the net to do > "server side includes" where the server read the file and included all > of the graphic images. There are issues about caching that my simple > description has entirely ignored but I hope you can see my point. You have the right idea, but the wrong terminology. Originally, the browser would request the HTML file, close the connection, then request each of the inline graphics as a separate (sometimes parallel) transaction. There is an extension know as 'keepalive' where after the initial transaction for the HTML file is completed, the connection can be kept open and used for additional requests, such as getting the associated graphics. KeepAlive is implemented in the Mosaic and Netscape browsers, and in many servers, including NCSA's and it's spinoff, Apache. ------------------------------ From: rishab@nntp1.best.com (Rishab Aiyer Ghosh) Subject: Re: Why is the Internet So Slow? Date: 28 Aug 1996 00:24:01 GMT Organization: Best Internet Communications Henry Baker (hbaker@netcom.com) wrote: > Bob Metcalfe was on CSPAN2 this morning talking about the 'collapse of > the internet'. A key point in his argument is that the internet is You might want to read George Gilder's piece in the latest (August 26) Forbes ASAP on Metcalfe's theory, and Internet slowdown in general. I'm not sure I agree entirely with Gilder's argument, but I find Metcalfe's simplistic. First, I don't see sufficient evidence to show that the rise of private Intranets will _slow_ down the Internet - this would mean the conversion of public networks to private ones, and I don't think this is happening. Most Intranets involve _new_ bandwidth; existing ones, like AT&T's, never were a thoroughfare for Internet traffic. We've seen it all before in the world's highways. Sure there are more traffic jams today than 50 years ago, but GM and Walmart still use public roads -- they haven't built nationwide private networks, because it's more expensive. Of course within their campuses and factories where security is important they use private roads, where the general public has no access. Traffic jams are being addressed in other ways, through tolls. Only recently have the Dutch started to use e-cash chips implanted in cars to automatically charge a fee for the use of congested roads. I would expect eventually similar technology to ease congestion on the Net, where it's only fair that those who use it more pay more, instead of being subsidised by low-volume users as at present. One point Gilder makes and Metcalfe could hardly dispute is that despite ever-more frequent traffic jams, the Internet, like the world's road network, is growing. And how! Rishab First Monday - The Peer-Reviewed Journal on the Internet http://www.firstmonday.dk/ Munksgaard International Publishers, Copenhagen International Editor - Rishab Aiyer Ghosh (rishab@dxm.org) Pager +91 11 9622 162187; Fax +91 11 2209608 or 2426453 or 2224058 A4/204 Ekta Vihar, 9 Indraprastha Extn, New Delhi 110092 INDIA ------------------------------ From: John B. Hines Subject: Re: Why is the Internet So Slow? Date: Tue, 27 Aug 1996 17:04:40 -0700 John Dreystadt wrote: > A standard web page often has many individual graphic > files. The standard model for HTTP involves what is best described as > "browser side includes". The main file for the web page is brought > over to the browser and the browser parses the file. Each graphic file > within the web page causes an individual file transfer using the HTTP > protocol to occur. It would be much less burden on the net to do > "server side includes" where the server read the file and included all > of the graphic images. There are issues about caching that my simple > description has entirely ignored but I hope you can see my point. But doesn't that defeat the user's option of not loading graphics? ------------------------------ Date: Tue, 27 Aug 96 18:39 EDT From: johnl@iecc.com (John R Levine) Subject: Re: Why is the Internet So Slow? Organization: I.E.C.C., Trumansburg, N.Y. > While there is much value in the overall message, there are some > technical errors in this paragraph. The HTTP protocol does not use > TCP/IP but instead uses the connectionless cousin, UDP/IP. Can you identify a Web server or client that uses UDP? I have looked at Netscape, Mosaic, Explorer, and Websurfer on the client side and NCSA, Apache, and the free Win95 server on the server side, and every single one of them uses TCP. Or were you perhaps thinking of something else? John R. Levine, IECC, POB 640 Trumansburg NY 14886 +1 607 387 6869 johnl@iecc.com "Space aliens are stealing American jobs." - Stanford econ prof ------------------------------ From: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman) Subject: Re: Why is the Internet So Slow? Date: 27 Aug 1996 15:50:44 -0400 Organization: MIT Laboratory for Computer Science In article , John Dreystadt wrote: > While there is much value in the overall message, there are some > technical errors in this paragraph. The HTTP protocol does not use > TCP/IP but instead uses the connectionless cousin, UDP/IP. I cannot let this "correction" stand. The sentence quoted above is absolutely, utterly false. Garrett A. Wollman wollman@lcs.mit.edu ------------------------------ Date: Mon, 26 Aug 96 13:28 EST From: James E. Bellaire Organization: Twin Kings Subject: Re: Why is the Internet So Slow? In TELECOM Digest 438 Pat noted: > So I took Bill Pfieffer's advice and 'moved to the Web' with the > Archives although I don't really know what to think about it at this > point in time. According to him, if one is not on the Web these days, > one might as well not be on the net at all. Some people write me to > say how poorly the web page is put together, but it was all pretty > much put together on the spur of the moment one evening in July, and > I am not so much interested in a pretty web page as I am in being able > to pass a large volume of text in as short a period of time as possible. > I do not think the web page looks all that bad, and I certainly do not > want to fall into the trap of lots of pictures and sounds. That just > isn't my thing, and the pages like that I have seen do seem to take a > very long time to load. I just don't know what I am going to do with > the Telecom web page at this point in time. PAT] The nicest part about TELECOM Digest web pages is that they are so compact. I use lynx from a shell account occasionally to grab something off massis without tying up a constant FTP link. The nicest thing about http vs ftp is that the connection drops and the host is free to serve others while the user processes the data. A compact, quick loading web page like TD's beats the 'lets see if I can crash this' design school. I once programmed on 4K basic machines. I went through the upgrade cycle (8K, 16K, 256K) before changing machines (the new one had 1 meg). Never could fill all of it, until I started on web pages. The high graphic web writers should be forced to view their creations over 14.4 modem lines at peak times. Then be sent to their rooms to write more compact code, doing as much as they can in as little code as possible. For those who still wouldn't learn we would give them 300 baud modems. A little remedial education would not hurt. :) James E. Bellaire (JEB6) bellaire@tk.com WebPage available 23.5 hrs a day http://user.holli.com/~bellaire [TELECOM Digest Editor's Note: Well you know, Lynx is what I use now to monitor the web page. I put the pages together using an emacs editor and manually inserted the HTML code where it belongs with advice given by Pfieffer. Since I do not have Netscape, Mosaic or any of those things here (sort of impossible to run over a 28.8 modem line to a Wyse-50 terminal) I just have to *assume* the web page looks okay, since I cannot view it on any regular basis other than via Lynx. But I do not want to sound too heroic here; I do walk over to the Skokie Public Library every few days and take my thirty-minute turn at the computers with Netscape installed on them to look at the web pages, make notes on what needs to be fixed, etc. Then I come back home and put it up in emacs and make whatever changes I want. So it is not like I am doing it entirely by guesswork as I edit it, although it is almost that way. Lynx then tries hard to show me what I did, but it becomes problematic. If someone would like to donate an old 486 with a good browser on it to the Digest, I'd be quite grateful and give them sponsor status. Trying to do this whole thing on a Wyse terminal was okay a few years ago, but it is starting to be a bit of a joke, and a stale one at that. PAT] ------------------------------ Date: Mon, 26 Aug 96 13:30 EST From: James E. Bellaire Organization: Twin Kings Subject: Re: Is the Internet Slow? In TELECOM Digest 438 dr@ripco.com (David Richards) wrote: > Your question is like asking the US Dept. of Transportation in D.C. > "Why is travel so slow?" > Some cities (providers) have major traffic jams, and there may be > construction and delays affecting some interstates, but overall the system > is very healthy. Actually the US DOT is running radio PSAs that feature a 'close call' on the highway (caused by poorly lit roads, pot holes, etc.) with a voice over that states 'on the 40th anniversary of the nation's interstate highway system the roads are falling apart, so watch out.' Strange ad ... James E. Bellaire (JEB6) bellaire@tk.com WebPage available 23.5 hrs a day http://user.holli.com/~bellaire [TELECOM Digest Editor's Note: Something else quite useful which I could see being adapted for the Internet are the little radio stations they operate at 530 kc and 1610 kc along each road to tell motorists about the conditions ahead of them. If there is not now, perhaps there could be a daily mailing circulated to network administrators which discussed bottlenecks located, general trends in network traffic, and ways around the problems. When an admin for example made some changes in his own configurations as a result of some chronic congestion at his own 'exit ramp' and 'on ramp' perhaps the daily announcement sent around would discuss this, and comment on adjustments others ought to be making as a result, etc. There may already be something like this, I don't know. But like the message the other day saying a bunch of files had been screwed up causing mail to bounce all over, it would be good if there were a standard method of alerting everyone 'on the highway' about the obstacles, wreckage, and congestion expected over the next day or two. Like air traffic controllers perhaps, but call them net traffic controllers. PAT] ------------------------------ From: rwells@usin.com (Roger Wells) Subject: Re: Will Full Number Portability Occur? Date: 28 Aug 1996 15:51:27 GMT Organization: U.S. Intelco Networks, Inc. In article , jeffrey.rhodes@attws. com writes: > National Number Portability does not promote competition for the local > loop so why is it needed? Sure one would never have to change numbers > but some new mechanism would be needed to inform callers about long > distance charges when calling a number that has been ported between > area codes. In addition to the convenience (or inconvenience, depending upon one's lifestyle and point of view) it makes more numbers available. There are NPA's with plenty of spare exchanges; with National Portability, these could be used elsewhere. Depending upon the scheme used, more area codes could be opened up: most probably, ten digit dialing would become mandatory (not absolutely required, but when most of the people who live close by have different leading digits on their phone numbers, it really doesn't make much sense to allow seven digit dialing for the occasional number halfway across the continent which just happens to have the same three leading digits.) This may be an inconvenience, but we seem to be coming to it anyway, and it would permit the second set of three digits in the phone number, which no longer indicates a specific exchange, to begin with 0 or 1. (In other words, all numbers--except special numbers like 911 -- are of the form NXX-XXX-XXXX.) As to a mechanism to inform callers about long distance charges, I think the scheme that has already been discussed would suffice. Any number can be dialed with a leading 1 if you are willing to pay long distance charges (or 0 for collect, calling card, etc.); with the leading 1 or 0 the call does not complete if it is long distance. Roger Wells ------------------------------ Date: Wed, 28 Aug 1996 10:46:54 -0500 From: clarkw@accesscomm.net (Clark R. Wilkins) Subject: Re: Will Full Number Portability Occur? As a side note to this discussion, what do other readers think about the prognostications that evolution of larger and larger scale packet switched networks would obviate the need for phone numbers as they are known? Is it possible that x-digit phone numbers will be irrelevant if we move more towards voice communication over IP-based networks? Would this not put the toll-based phone system out of business (or into another business) if bandwidth becomes a commodity item? Also, I thought the (little discussed) idea of converting phone numbers from seven to eight digits by adding another digit on the end and reserving the block of ten (aaa-aaaa0 through aaa-aaaa9) for valid and existing seven digit numbers was absolutely brilliant. All other schemes I have seen seem to involve adding more complexity and less automation, whereas this one changes nothing for existing numbers. Clark R. Wilkins * President, J.D.I. Solutions, Inc. 713-974-2434 (f) 713-974-5248 ------------------------------ Date: Tue, 27 Aug 96 20:37 EDT From: johnl@iecc.com (John R Levine) Subject: Re: Will Full Number Portability Occur? Organization: I.E.C.C., Trumansburg, N.Y. Al predicts: > As telecom usage rises and prices fall, folks will be more willing to > place calls without knowing the exact costs -- look at cellular usage. > (Note that some folks pay more to take their own money out of ATMs than > for many phone calls - it all depends on "what you're used to".) I wish I believed that. Toll rates have fallen by, what, two orders of magnitude in real terms in recent decades, but the majority of the country still clings to the 1+ for toll anachronism. > TELCos will get into the information content area, because that's where > the money is -- today. Right, and when they do it we'll know that market is where the money was yesterday. John R. Levine, IECC, POB 640 Trumansburg NY 14886 +1 607 387 6869 johnl@iecc.com "Space aliens are stealing American jobs." - Stanford econ prof ------------------------------ From: david@cs.uow.edu.au (David E A Wilson) Subject: Re: Correction: Microsoft and the Apple II Date: 28 Aug 1996 13:49:58 +1000 Organization: University of Wollongong, NSW, Australia. In article , TELECOM Digest Editor wrote: > Inc. model C-1-P, with 4K of RAM which I got in 1977. It used > [TELECOM Digest Editor's Note: Yes, you are correct and I stand > corrected. DOS and BASIC had (still have) nothing to do with each > other. In fact on the OSI you loaded the BASIC into RAM each time > you turned on the computer by playing a tape from a little cassette > player which you plugged into the side of the computer. There were > no disk drives, etc on the OSI. If you wanted to save a program you > saved it back out to the tape on the cassette player. No disk and > therefore no isk perating ystem. PAT] I too started my home computer career with an OSI C1P. I think mine was circa 1978 so it may have been a little more modern than yours. It did have a disk drive system available as an option but I never purchased it. Loading programs from tape was cute -- the LOAD command simply changed the input vector to use the 6850 connected to the tape recorder and a BASIC listing on the tape simply typed itself in. Further, it had Microsoft's 8KB 6502 BASIC in ROM in addition to a 2KB monitor ROM which turned out to be two 1KB monitors, one for the larger OSI machines and one for the Superboard/C1P (the C1P = Superboard + Case/PSU). The prompt you got when you powered it up was D/C/W/M? for Disk/Coldstart_BASIC/Warmstart_BASIC/Monitor. The disk controller wrote bytes to the disk using a 6850 to serialize the data and a 6821 to step the drives etc. The major limitation was the video - 32 rows x 32 cols of 8x8 characters with no vertical or horizontal overscan resulting in a usable area of about 24x24. In later years I tripled the master clock to get 96 horizontal cells and used 32 of them for horizontal blanking. Increasing the vertical line count from 32 to 38 gave me some vertical blanking and a 50Hz refresh more suitable to Australia. David Wilson Dept CompSci Uni Wollongong Australia david@cs.uow.edu.au [TELECOM Digest Editor's Note: Mine had the same opening prompt and the same screen display. You had to be very careful with the volume control on the tape recorder when you saved out and loaded in the programs. If it was too loud or too soft, the transfer would go badly and you had to start all over again. PAT] ------------------------------ TELECOM Digest is an electronic journal devoted mostly but not exclusively to telecommunications topics. It is circulated anywhere there is email, in addition to various telecom forums on a variety of public service systems and networks including Compuserve and America On Line. It is also gatewayed to Usenet where it appears as the moderated newsgroup 'comp.dcom.telecom'. Subscriptions are available to qualified organizations and individual readers. Write and tell us how you qualify: * ptownson@massis.lcs.mit.edu * The Digest is edited, published and compilation-copyrighted by Patrick Townson of Skokie, Illinois USA. You can reach us by postal mail, fax or phone at: Post Office Box 4621 Skokie, IL USA 60076 Phone: 847-329-0571 Fax: 847-329-0572 ** Article submission address: ptownson@massis.lcs.mit.edu Our archives are located at mirror.lcs.mit.edu. The URL is: http://mirror.lcs.mit.edu/telecom-archives They can also be accessed using anonymous ftp: ftp mirror.lcs.mit.edu/telecom-archives/archives A third method is the Telecom Email Information Service: Send a note to tel-archives@mirror.lcs.mit.edu to receive a help file for using this method or write me and ask for a copy of the help file for the Telecom Archives. ************************************************************************* * TELECOM Digest is partially funded by a grant from the * * International Telecommunication Union (ITU) in Geneva, Switzerland * * under the aegis of its Telecom Information Exchange Services (TIES) * * project. Views expressed herein should not be construed as represent-* * ing views of the ITU. * ************************************************************************* Finally, the Digest is funded by gifts from generous readers such as yourself who provide funding in amounts deemed appropriate. Your help is important and appreciated. A suggested donation of twenty dollars per year per reader is considered appropriate. See our address above. All opinions expressed herein are deemed to be those of the author. Any organizations listed are for identification purposes only and messages should not be considered any official expression by the organization. ------------------------------ End of TELECOM Digest V16 #447 ******************************