Figure 1: Total load on 2 Mb/s data link Deakin University Toorak to
Monash University Clayton, 21 June 1996. (Screen dump modified to show total load only.)
| Australian Journal of Educational Technology 1996, 12(1), 56-77. |
AJET 12 |
Bandwidth conservation by personal computer end users appears to be a concept that has received little attention. The focus of bandwidth conservation activity has been on items such as the establishment of mirror sites, proxy servers and institutional caching, or on techniques to be employed by Web page developers to reduce network traffic caused by icons and other graphic objects. This paper explains bandwidth in non-technical terms and why its conservation is important. It lists actions that can be taken by computer end users on the Internet in the interest of conserving bandwidth.
This dramatic upsurge in data flow emanates from an increased number of users accessing the Net (.5-1 m in Australia, 43 m world wide, through an increased number of nodes) and through a shift in the nature of network traffic, which has changed from primarily being file transfer (FTP) use to primarily being World Wide Web use. In fact, the recent popularisation of the Internet has largely been a consequence of the success of the World Wide Web, occasioned by its now user-friendly Web browsers and support for interactivity. Interactivity, however, has come at a price, since the Web's support of such media as sound, pictures, QuickTime(TM) movies, desktop video conferencing and telephony has meant a shift from activities involving small traffic load to activities that involve high bandwidth use and thus increased scope for bottlenecking of data. In addition, the Web's growing popularity, not surprisingly, has attracted the attention of the world of commerce, which in turn is contributing to the current growth phase.
The response of those involved in maintaining networks, whether they be LANs or Telstra, has been to attempt to progressively increase available bandwidth in an endeavour to meet the spiralling demand. An additional approach that has not been promoted is to encourage Net practices that result in conservation of bandwidth, so limiting expenditure on bandwidth infrastructure.
Telstra Internet has its own Australian backbone, and for connection to North America and Intemet worldwide leases from a cartel part of bearers across the Pacific. It then on-sells bandwidth to universities and other organisations at commercial rates. These are not inexpensive. Details of Telstra's Internet tariff can be obtained from Telstra's Web site [HREF1].
The price of the trans Pacific link is closely approximated by the figure $150,000 per month per 2 megabits per second (Mb/s). The price of an intercapital 2 Mb/s link varies from about $206,000 up to $262,000 per annum plus a $9,000 installation charge. Figures are as at May 1996. Two Mb/s is a typical bandwidth used by Telstra Internet within Australia.
An increasing demand for bandwidth by Australian universities cannot be sustained in an environment of diminishing government funding. So in universities and other education sectors, bandwidth conservation becomes an important issue for academics, administrative staff and students alike. It is becoming imperative to view bandwidth as a precious resource and not a resource of unlimited availability. By way of example, Box Hill College of TAFE reports: 'Our Internet connection is a valuable but limited resource to be shared by all that want to use it. It is also an expensive one. The original 9600 baud connection cost around $7,000. Upgrading to 64 kb increased the charges to $18,000. With Telstra as the new maintainers the predicted ISDN connection charges for 1996 are $100,000 plus' [HREF2].
The major cause of slowness on the Internet is lack of bandwidth to meet demand. Bandwidth available now is arguably insufficient in some parts of the network. A major bottleneck has been the Pacific link to North America which was increased in December 1995 from 6 Mb/s (megabits per second) to 18 Mb/s, was further increased in April-May 1996 to 24 Mb/s, and was increased yet again in July 1996 to 32 Mb/s. This has resulted in a major improvement of the performance of the Pacific link. Prior to these improvements it had been suggested that to meet existing demand and reduce slowness in a major way would require 622 Mb/s (the next bearer configuration up from 155 Mb/s) at a cost that only Bill Gates could afford! However new technology has a habit of rapidly changing situations, and the introduction of asynchronous transfer mode (ATM) switching technology is beginning to do just that by massively increasing the rate at which data is transmitted. The need for bandwidth conservation could evaporate, but is relevant at the present time. The adoption of ATM technology is not guaranteed and in any case will take time. Besides there remains the question of whether technological advancements that effect improvements in data flow can keep pace with the burgeoning demands of conferencing and multimedia.
The description of bandwidth given above begs the question of what bandwidth is. If we decide we want to conserve it, it is helpful to have a broad understanding of what it is that we are conserving, and how a change in Net practices helps. This is best done in the context of a description of the Internet.
The movement of packets is similar to the movement of envelopes in the mail system. Each packet has an address, and gateways and routers act as sorting houses in which each packet that goes in also comes out as it is forwarded towards its ultimate destination.
A more detailed explanation of the Internet is to be found at the site referred to in [HREF3]
Figure 1: Total load on 2 Mb/s data link Deakin University Toorak to
Monash University Clayton, 21 June 1996. (Screen dump modified to show total load only.)
By way of contrast, Figure 2 shows a maximum load on 21 June 1996 on the Deakin Waurn Ponds (Geelong)-Monash University link of about 1.7 Mb/s and a load of around 1 Mb/s for most of the day. As the link has a capacity of only 2 Mb/s for data, this is an indication of a link that is definitely under pressure. At times the link hits its capacity.
The University of Adelaide has histograms showing details of trip round times (in milliseconds) on each major university link and of the link across the Pacific to the MCI (MCI Telecommunications Corporation) gateway at San Francisco and thence to Los Angeles (Figure 3) [HREF5]. Also shown is delay (in milliseconds) and more significantly, packet loss. All elements are shown by hour of day.
Figure 2: Total load on 2 Mb/s data link Deakin University Waurn Ponds (Geelong) to
Monash University Clayton, 21 June 1996 (screen dump modified to show total load only).
The concept of packets and packet loss needs some explanation. Activities on the Net involve data flow. Data is split into packets, into small chunks of data (not diagnostic packets). These packets are disassembled, transmitted, and then reassembled. To get to their destination they travel along bearers and through gateways and routers. They may take different routes to their destination. Along with each packet there are generally checksums and acknowledgments. lf the checksum is corrupted on arrival, then packet loss occurs and the packet has to be retransmitted. If an acknowledgment is sent, but not received within a certain time window, then a packet is retransmitted. This packet loss is what often happens in overloaded networks - they end up spending significant time retransmitting, effectively adding to the load (Warren, C. 29 April 1996). Note also that the bigger the file size transmitted, the more packets there will be and the longer it will take them to rejoin at destination.
Packet loss is an indicator of slowdown when load is high. Packet loss in the range of 5-10% is considered bearable, but usually indicative of a problem; over 10% is considered to be problematic in a major way. So of particular interest is the packet loss on the link to the point in California where connection is made to the MCI Telecommunications Corporation network at San Francisco, as the Pacific link has been a known bottleneck. Figure 3 shows the packet loss on the Adelaide link to MCI Los Angeles via San Francisco on 6 May 1996 [HREF6], and shows an average packetloss of 18.18% stated as being over 22 hours, but peaking at 51% at 12 noon. Although the extent of packet loss is given, a limitation is that where the packet loss occurs is not shown. It may be as a result of poor performance on the link between San Francisco and Los Angeles rather than on the link across the Pacific.
Also given at the University of Adelaide site (Figure 4) are the results of a traceroute to the same host computer. A traceroute is achieved by the sending of a special diagnostic packet of data from one router to another to provide information as to the route taken, whether connectivity was present and routing was working correctly through the network during the trace, and the round trip time maximum, average and minimum taken in milliseconds for each hop along the way. Note the jump in round trip times between the point of departure in Australia and the point of arrival at San Francisco, USA. Tracerouting is a measure of the speed of the bandwidth rather than of its utilisation. It is not a measure of bandwidth performance.International Link
Traffic to MCI-LA
HR Loss 10 20 30 40 50 60 70 80 90 Trip Delay % +----+----+----+----+----+----+----+----+----+----+ ms 00 27 *XXXX*XXXX*XXX | | | | | | | | 305 0.10 01 20 *XXXX*XXXX* | | | | | | | | 341 0.01 02 0 * | | | | | | | | | | 270 0.00 03 7 *XXX | | | | | | | | | | 270 0.00 04 13 *XXXX*X | | | | | | | | | 540 0.00 05 0 * | | | | | | | | | | 251 0.00 06 6 *XXX | | | | | | | | | | 513 0.00 07 8 *XXXX| | | | | | | | | | 406 0.00 08 20 *XXXX*XXXX* | | | | | | | | 233 0.01 09 29 *XXXX*XXXX*XXXX| | | | | | | | 240 0.11 10 34 *XXXX*XXXX*XXXX*XX | | | | | | | 226 0.15 11 31 *XXXX*XXXX*XXXX* | | | | | | | 247 0.13 12 51 *XXXX*XXXX*XXXX*XXXX*XXXX* | | | | | 280 0.34 13 34 *XXXX*XXXX*XXXX*XX | | | | | | | 324 0.15 14 0 * | | | | | | | | | | 0 0.00 15 0 * | | | | | | | | | | 0 0.00 16 18 *XXXX*XXXX| | | | | | | | | 427 0.01 17 24 *XXXX*XXXX*XX | | | | | | | | 296 0.04 18 5 *XX | | | | | | | | | | 274 0.00 19 6 *XXX | | | | | | | | | | 303 0.00 20 14 *XXXX*XX | | | | | | | | | 271 0.00 21 7 *XXX | | | | | | | | | | 263 0.00 22 1 * | | | | | | | | | | 257 0.00 23 45 *XXXX*XXXX*XXXX*XXXX*XX | | | | | | 350 0.26 +----+----+----+----+----+----+----+----+----+----+ Average packet loss over 22 hours = 18.18%Figure 3: University of Adelaide to MCI Los Angeles packet loss 6 May 1996.
A return to tracerouting will be made later.Traceroute to core1-fddi-0.LosAngeles.mci.net
1 fddi0-0.exchange.saard.net (203.21.37.2) 1 ms 2 ms 1 ms 2 Serial4-5.way-core1.Adelaide.telstra.net (139.130.237.1) 6 ms 2 ms 1 ms 3 Serial5-5.pad-core2 Sydney.telstra.net (139.130.249.209) 19 ms 17 ms 17 ms 4 national-new.gw.au (139.130.249.228) 19 ms 27 ms 20 ms 5 cpe4-hssi1-0.SanFrancisco.mci.net (204.70.204.5) 240 ms 217 ms 245 ms 6 border2-hssi3-0.SanFrancisco.mci.net (204.70.33.9) 232 ms 224 ms 230 ms 7 core1-fddi-1.SanFrancisco.mci.net (204.70.3.161) 232 ms 414 ms 267 ms 8 core1-hssi-3.LosAngeles.mci.net (204.70.1.154) 281 ms * 235 msFigure 4: University of Adelaide traceroute to the MCI network 6 May 1996.
Another site that contains network performance details of interest is that of Telstra. It emits a sequence of 50 ICMP ECHO_REQUEST protocol type diagnostic packets at random minutes within each hour. From these packets, a measure is made of Internet performance which is shown as percentage of on-time packets delivered over a given period [HREF7].
Telstra also provides performance graphs [HREF8], an example of which is found in Figure 5.
Table 1 provides details of average packet loss on 10 May 1996 to USA and each State and Territory of Australia, the same day as the performance graph in Figure 5. Note that packet loss is highest for the link to US-HAYWARD. Similar data taken on 6 May 1996 showed a packet loss of 18.88% to US-HAYWARD, this being of a similar high order to the 18.18% packet loss from the University of Adelaide to MCI-LA the same day and shown in Figure 3.Traffic to US-HAY
Figure 5: Telstra performance graph for 10 May 1996 for traffic to US-Hayward, in the Bay of San Francisco, a part of the USA where a lot of links ground. Average packet loss over 288 measurements was 6.97%. The days immediately following 10 May 1996 showed smaller packet losses.
| Traffic to: | Average packet loss |
|---|---|
| US-HAYWARD Western Australia South Australia Queensland Victoria Tasmania New South Wales Northern Territory Australian Capital Territory |
6.97% 0.06% 0.18% 0.11% 5.67% 0.04% 0.81% 0.28% 0.34% |
Since overload is the biggest factor in slowness on the Internet, information on load, packet loss and bandwidth will be of major significance in analysing network performance. That analysis may indicate that an increase in bandwidth is desirable. It may also indicate a point at which bandwidth conservation of varying kinds would save the capital cost of such an increase. Regretfully there appears to be no Australian Web site that shows where packet loss occurs. However, on a link from a site in Australia such as from the University of Adelaide to MCI-LA as shown above it has traditionally been most likely to have occurred in the Pacific sector.
To further an understanding of bandwidth, it will be helpful to detail bandwidth at a local and national level and also detail bandwidth for the link to North America and the wider Internet. So Deakin University's network will be briefly detailed as an example of a local network, Telstra's Australian Internet core will be detailed as the national Internet network, and its link to North America and the wider Internet will also be briefly detailed. It needs to be recognised that this is not a static environment and that changes in the bandwidth of links are made from time to time if not frequently. The figures shown are those as at the dates stated.
Figure 6: Deakin University Network showing bandwidth for bearers and data as at 8 July 1996.
Figure 7: Telstra Internet core for data as at 5 July 1996.
Figure 8: The Internet Pacific Link.
Beyond the entry point to USA lies the world wide Internet where the routes taken by packets can be many and varied. As mentioned above, a traceroute packet can give route details. An example of a traceroute showing the route to the MCI Telecommunications Corporation network at Los Angeles and beyond to the network of the University of Michigan is shown in Figure 9. This was generated using MacTraceroute on a Macintosh nubus personal computer at the Burwood Campus of Deakin University. The return trip times for hops along the way are relatively unreliable and difficult to interpret so do not dwell on them.
The route shown in Figure 9 is from Building A at Deakin University Burwood, to Monash University Clayton Menzies Building, to Melbourne University Thomas Cherry Building, to Lonsdale St. Exchange Melbourne, to Paddington Exchange Sydney, to Los Angeles (California), to San Francisco (California), to Sacramento (California), to Willow Springs (Missouri), to Chicago (Illinois), to Ann Arbor - University of Michigan, (Michigan). The traceroute is:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
139.132.26.254 134.132.2.254 139.130.12.1 139.130.16.1 192.43.209.1 139.130.239.53 139.130.239.226 139.130.249.21 139.130.249.228 204.70.173.5 204.70.170.17 204.70.1.153 204.70.1.54 204.70.1.146 204.70.1.174 204.70.1.85 204.70.2.82 204.70.24.6 192.203.195.4 198.108.3.2 141.21.10.11 141.211.1 20.11 |
ba-gw1.net deakin.edu.au megrez net.deakin.edu.au vic-east.gw.au national.gw.au national.gw.au vic.gw.au. fddi0-0.lon-core1.melbourne.telstra.net serial4-5.pad-core1.sydney.telstra.net national-new.gw.au border3-hssi1-0.losangeles .mci.net core1-fddi-0.losangeles.mci net core-hssi-2.sanfrancisco.mci.net core2-aip-4.sanfrancisco.mci.net core1-hssi-2.sacramento.mci.net core1-hssi-2.willowsprings.mci.net core-hssi-3.chicago.mci.net border1-fddi-0.chicago.mci.net merit-michnet-ds3.chicago.mci.net fdd0.michnet1.mich.net f-umbin.c-ccb.umnet.umich.edu f-backbone.c-ang1.umnet.umich.edu carpediem.ccs.itd.umich.edu |
1 10 5 14 24 163 165 98 70 329 409 * 463 * 378 * 523 373 458 700 * * |
2 38 4 14 6 54 288 97 124 * 606 * * * 451 * 535 374 * 513 492 380 |
3 5 8 6 11 185 86 140 40 350 660 547 * 345 385 393 * 423 * 564 * * |
Details of the bandwidth of the pipes beyond Los Angeles are not available. Figure 10 shows the approximate route on a map. Note that since this traceroute was taken the entry point to USA of the Pacific link has shifted from Los Angeles to San Francisco.
Figure 10: The route taken by a traceroute from Burwood, Melbourne, Australia to Los Angeles, USA to the University of Michigan, Ann Arbor, 60 kilometres west of Detroit. Since the traceroute was taken on 3 April 1996, the Honolulu (Hawaii) to USA sector of the Internet Pacific link has been changed to go from Honolulu to San Francisco direct.
Nevertheless, the contribution that end users can make is significant. Some change in Net practices will have greater impact than others. For example, as signatures in e-mail messages do not take a lot of bandwidth, not a lot is gained from a reduction in their size. Turning off a Web browser's automatic loading of images would have a much more dramatic effect. Similarly if every person accessing the Web had their Web browser set to open a local site instead of opening a site in USA such as the Netscape home page, a considerable saving of bandwidth would be made. The combined effect of the practices suggested below would be well worthwhile - every piece of bandwidth conservation helps.
The clearest of these is to save limited financial resources. In the same way as conservation of electricity may make the building of another power station unnecessary, so the conservation of bandwidth by end users may render unnecessary an uplift in expensive bandwidth, or as has been mooted, the mounting by IBM and AT&T of Internet II for business.
Academics and others must ask whether access is a right or a privilege. Presently access for most academics is unlimited, and a failure to wisely use the resource now available will ensure its withdrawal or restriction. Even end user conservation of bandwidth will be no guarantee of continued unlimited access.
Since a consequence of conserving bandwidth is less load on networks, an outcome of conserving will be a speedier network and a saving of the time of end users waiting for something to happen. Although there are techniques for going off and doing other things while network requests are processed, there is a tendency to concentrate on one thing at a time and wait for responses to be completed before doing anything else.
We can choose to act as citizens of the world and accept social responsibility for the consequences of our actions. That may lead us to change some of our Net practices. If, however, we choose not to so accept responsibility, then our excesses, when combined with those of others will very likely result in a slower Net performance.
A lack of action could even imperil the viability of the resource. End users may wish to help avert a scenario in which insatiable demand for bandwidth results in unaffordable bandwidth and the collapse of Internet!
By the way, it is people who use bandwidth and people who can conserve it! So here is a list!
| 1. | Conserving bandwidth when on the WWW |
| 1.1 | Use caching on your personal computer Browsers such as Netscape have the ability to perform local caching on your personal computer and implement institutional caching where this is available. This is a process in which the data of a Web page that is accessed is temporarily stored. Thus, if you return to that page during a session, further bandwidth is not used in re-capturing that page. Instead, when you click Forward or Back to return to a Web page, your computer accesses the temporary file.
Having preferences and proxies set to enable caching makes an important contribution to bandwidth conservation as it is common practice to return to previously downloaded Web pages. Saves your time as well! |
| 1.2 | Stop unwanted downloads Consumption of bandwidth in downloading data such as a page or an image from a page ceases as soon as you stop downloading, and you can terminate downloading at any time. This is achieved by such actions as clicking the stop button, clicking another link or clicking Forward or Back. So if you judge the page or image on a page is not one you want before its downloading is complete, take action to stop downloading.
Recognise that some Web page creation software provides for the automatic
initial sending of a low resolution GIF image followed by a higher resolution one.
Similarly interlaced GIF images can be followed by progressive JPEG images.
That's technical, but either way you are given an improved chance to
determine that you no longer wish to view a page or image and stop downloading while
the bandwidth load is lower. |
| 1.3 | Turning off your Web browser's automatic loading of images when not required When you can get the information you seek without viewing images, do. The consequent non-downloading of Web page images will save much bandwidth as well as page downloading time. |
| 1.4 | Set your Web browser on opening to access a local site Instead of opening a site in USA such as the Netscape home page, your Web browser can be set to open a local site such as a university home page. This will avoid unnecessary data flow across the Pacific link or the Telstra Internet core. By everyone doing this, the aggregate saving of bandwidth would be considerable. If your institution operates a cache, then opening to the Netscape home page would not take you to USA, but would access the local institutional copy, in which case no bandwidth saving would be made. |
| 1.5 | Access mirror sites in your own country wherever possible Wherever possible, access mirror sites in your own country rather than accessing the same data on sites overseas. On the WWW there appears to be two different kinds of mirroring. The first is the total or near total mirroring by one Web site of another Web site. There do not seem to be many Web sites of this ilk. Nevertheless, an example of a WWW site that mirrors another WWW site is the University of Adelaide's 'Web Museum, Paris' [HREF11], which mirrors its French counterpart [HREF12]. Also, Curtin University has a Web site 'Welcome to the Planets' which mirrors a National American Space Agency site 'Welcome to the Planets' [HREF13], a collection of many of the best images from NASA's planetary exploration program [HREF14]. There does not appear to be a listing of these kinds of mirror sites. One way of locating such sites relevant to your own interests might be to use the Little Aussie Web Wombat Australian Search Engine [HREF15] and search for 'mirror web site'. A less likely method might be to check whether the overseas site in which you have an interest has an Australian counterpart by searching a list of Australian Web sites maintained by Charles Sturt University [HREF16]. The second type of mirroring involves the WWW as an interface for downloading files from FTP (File Transfer Protocol) servers. Many sites store software and other data that can be downloaded bv this means. An example is that of the Australian SunSITE (Software Information and Technology Exchange) [HREF17], a joint project of The Australian NTational University and Sun Microsystems, which is a repository of public domain software, much of it mirrored from overseas sources. Two USA sites INFO-MAC and UMICH containing Macintosh software are, for example, mirrored in this way at this site, as is Netscape software. Another Australian Web site for Macintosh software is at the University of New South Wales [HRFF18] The accessing of mirror sites so as to download files by FTP is discussed further below. In order to conserve bandwidth, where they exist, develop a list of mirrors of overseas sites you regularly visit and store the list as a bookmark. Where relevant to you, become familiar with the frequency of the updating of these mirror sites as this may be important to your search enquiry. An enquiry by email to the webmaster at the mirror site should result in your acquiring that information.
The best idea with the Internet is to 'think globally, act locally' where possible. |
| 1.6 | Cease downloading files if downloading rate is too slow Be aware that downloading of web pages and files may occur at a speed well below the capability of your modem or of your ethernet connection, and may fluctuate during downloading. Consider not downloading if the rate becomes too slow, as it is probably an indication of network overload and thus there is an increased likelihood of packets needing to be retransmitted, so causing a further increase in bandwidth consumption. By ceasing to download in situations where downloading is intolerably slow you will help spread consumption of bandwidth. You are also likely to help reduce packet loss. Another less radical way of dealing with slow downloading is to instruct your Web browser not to download graphics, a matter already discussed.
Note that your Wob browse may allow you to have multiple windows open, so you may be able to put your Web browser in the background and get on with something else - but this conserves your time, not bandwidth. Note that small files generally download speedily but large files show variability in the rate of downloading. This is because of the 'packet' approach to downloading. Files go down the line in chunks. With queuing, parts of files can go down different routes before being reassembled. Larger files are more likely to be subject to this process and thus take longer to be reassembled and received. |
| 1.7 | Access the WWW at times of low load Accessing the WWW at times of high load probably means you are using the Net at a time of high packet loss, adding more to network load and contributing further to packet loss. You can tell if the load is high from slow response times and slow rates of downloading files or Web pages.
Be aware of the factors that contribute to better or worse access. Around 9.00 am AEST is generally the worst time as users log on. Accessing USA sites when USA is asleep may be an idea, but when USA is asleep, Australia is awake. Factors may be local (e.g. at University level for batch processing) or at gateways along the line. There is no rule as to the best time, but generally early morning is best. Experience may inform you of the best access hmes. An enquiry from the group that manages your network may also provide useful information. |
| 1.8 | Do not subscribe to a news group server unless it is on your local system To reduce network traffic, always subscribe to a news server on your local system if it is available; if not, subscribe to the nearest public access news server. Subscription to a news group server that is not on your local system causes excessive network traffic. Note that some if not most Internet service providers do not offer a news group server service, and there are apparently very few public access news servers in Australia. If belonging to a news group is important, lobby your Internet service provider for that facility [HREF19 and HREF20].
This principle also applies to non-WWW subscriptions to news group servers. |
| 1.9 | Consider thumbnail graphics before downloading the expanded version of the graphic If a thumbnail graphic is available, use its availability to consider the importance of viewing the expanded file before downloading in case you do not want it. For an example of thumbnail graphics, see the router utilisation graphs at the site referred to in [HREF4]. By carefully considering these, a selection could be made of the graphs to be viewed in detail. |
| 1.10 | Close sessions, as a general rule, that involve real-time streaming of data as soon as you are no longer engaging in them This applies to applications such as audio and video conferencing and multimedia taking place in real time. Immediate closing of these kinds of sessions after completing what you need to do will save bandwidth considerably. RealAudio is a specific example in which large amounts of bandwidth are consumed whilst you are connected. Be aware of different situations in which these kinds of applications can be used such as group video conferencing with CU-SeeMe across Telstra Internet or across the Pacific, compared with group video conferencing within an organisation on its local area network. The former will be much more consumptive of expensive bandwidth than the latter. Since conferencing and multimedia can consume very considerable amounts of bandwidth, and since these forms of use of the Web are rapidly increasing, conservation of bandwidth as suggested here will in future take on added significance. |
| 2. | Conserving bandwidth when using email |
| 2.1 | Before replying to an e-list message, check whether your reply is going to the intended recipient Messages by way of reply that are intended for the originator of the e-list message are sometimes inadvertently sent to the e-list instead of to the originator. Check the 'Reply to:' section of your message header to avoid a message being unnecessarily replicated, perhaps to your own embarrassment! Bandwidth savings will be small unless it is a large reply to a large list! |
| 2.2 | When replying to an email message, remove text from the original message that is irrelevant to the latest contribution Similarly to keeping signatures to a minimum (see below), keep you replies to a minimum by either not resending the sender's message or only resending those parts that are directly connected with your reply. Careful subject labelling will ensure correct identification. Bandwidth savings will be small but the aggregate could be substantial, especially where there are multiple recipients. Besides, they can be an annoyance to readers. |
| 2.3 | Compress large files before sending Shareware and commercialware are available which enable files to be compressed prior to sending, thus reducing the amount of data, the number of packets transmitted and the transmission time. Besides, the receiver's chances of receiving it before a line drop out may be increased! There is some time needed to compress files, so for the saving to be worth while, you probably need to be dealing with a file size of around 500 kB or more. |
| 2.4 | Keep signatures to a minimum Signatures at the foot of e-mail messages consume small amounts of bandwidth. Savings can be made by keeping signatures to a minimum. This is becoming less of a bandwidth issue as large bandwidth usage such as real time multimedia activity increases.
Overall, the practices advocated for e-mail are more netiquette than serious bandwidth conservation measures. |
| 3. | Conserving bandwidth when downloading files using FTP |
| 3.1 | Stop unwanted downloads If you decide the file is not one you want before its downloading is complete, take action to stop downloading. |
| 3.2 | Download files from mirror sites in your own country wherever possible Wherever possible, whether FTP'ing through the WWW or using an FTP application such as Fetch or WS_FTP, download files from FTP mirror sites in your own country rather than download the same data from sites overseas. The downloading of files whilst using a Web browser has been considered above, and special reference made to the Australian SunSITE, which can be accessed at sunsite.anu.edu.au. Other useful Australian FTP sites that mirror overseas sites can be located at University of Melbourne, University of Adelaide, Curtin University and University of Canberra Computer Society [HREF21]. This list is not exhaustive. A search for these sites can be made from a site at the University of Queensland [HREF22]. Archie.au at The Australian National University has mirrors of software archives for computers, including Macintosh, Windows, and Unix. This can be accessed using an FTP application. Access via a Web browser can be achieved from Curtin University's WWW site [HREF23].
As noted above, develop a list of mirror sites you regularly visit. |
| 3.3 | Cease downloading if downloading rate is too slow See paragraph 1.6 above of 'Conserving bandwidth when on the WWW'. The principle espoused there applies equally to non-WWW downloading. See also paragraph 1.7 above (Access the WWW at times of low load) as the downloading rate will be slow in times of high load. |
Feibel, W. (1995). Novell's complete encyclopedia of networking. Almeda, CA: R. Kearsley.
Warren, C. Email to author 29 April 1996.
Whittle, R. Email to author 9 October 1996.
[HREF2] http://www.bhtafe.edu.au/CIS/misc/bhtc-proxy.htm [see http://www.bhtafe.edu.au/]
[HREF3] http://www.ozemail.com.au/~firstpr/contreg/crguide.htm
[HREF4] See http://www.deakin.edu.au/~ccw/router-stats/index.html
[HREF5] http://traffic.saard.net/Pings/l996/05/06.html [ see http://traffic.saard.net/Pings/ ]
[HREF6] http://traffic.saard.net/Pings/l996/05/06.html [ see http://traffic.saard.net/Pings/ ]
[HREF7] See http://www.telstra.net/ops/perf.html for Telstra Internet performance statistics.
[HREF8] Derived from http://www.telstra.net/ops/pings/index.html
[HREF9] Derived from the Telstra Internet Map 5 July 1996 at http://www.telstra.net/telstra/map.html [ see http://www.telstra.net/graphics/webmap.gif ]
[HREF10] See for example Bandwidth Conservation Society at http://www.infohiway.com/faster/, Australia This Minute at http://acslink.net.au/~tomw/atmhow.html, and Vanzyl, A., "Increasing web bandwidth through image compression: An overview of GIF, JPEG and Fractal compression strategies at http://www.scu.edu.au/sponsored/ausweb/ausweb95/papers/management/vanzyl
[HREF11] http://www.netspot.unisa.edu.au/louvre
[HREF12] http://www.cnam.fr/louvre/
[HREF13] http://www.curtin.edu.au/mirror/planets/
[HREF14] http://scruffy.phast.umass.edu/welcome.html
[HREF15] http://uiop.intercom.com.au/wombat [ see http://www.webwombat.com.au/wombat/
[HREF16] http://www.csu.edu.au/links/ozmap.html
[HREF17] http://sunsite.anu.edu.au/archives
[HREF18] http://mac.unsw.edu.au/web/newfiles.html [ see http://mac.unsw.edu.au/mac/archive.html ]
[HREF19] Tebbutt, D. "How to configure you web browser for usenet news reading", at http://www.ozemail.com.au /~dtebutt/rsrc/webnewssetup.html
[HREF20] A list of news servers can be located at http://wopr.cs.utas.edu.au/open-news-servers
[HREF21] University of Melbourne: http://www.unimelb.edu.au/public/aumirrors.html
University of Adelaide: ftp://ftp.adelaide.edu.au
Curtin University: http://www.curtin.edu.au/mirror/
University of Canberra Computer Society: http://blitzen.canberra.edu.au/links/ftp.html
[HRE 22] http://www.psy.uq.edu.au/mirrors/search.html
[HREF23] http://www.curtin.edu.au/mirror, or direct by using ftp://archie.au
| Author: Noel Jackling is a Lecturer in the Centre for Academic Development of Deakin University. He works as an educational developer. Noel Jackling, Deakin Centre for Academic Development, Deakin University, 221 Burwood Highway, Burwood, Vic 3125. Tel: (03) 9244 6495. jackling@deakin.edu.au
Please cite as: Jackling, N. (1996). End user bandwidth conservation: What can Internet end users do? Australian Journal of Educational Technology, 12(1), 56-77. http://www.ascilite.org.au/ajet/ajet12/jackling.html |
