CLOSED ENVIRONMENT TESTING OF ISP-LEVEL INTERNET CONTENT FILTERS docx

The report commences with definitions of the four criteria against which the capability of ISP­level filtering technologies was assessed: performance; and block illegal content, content

Closed Environment Testing 

of ISP０Level Internet Content  Filters 

Report to the Minister for Broadband, Communications and the  Digital Economy 

Purple Building, Benjamin Offices  Level 44, Melbourne Central Tower   Level 15, Tower 1 Darling Park 

Chan Street, Belconnen  360 Elizabeth Street, Melbourne  201 Sussex Street, Sydney 

Belconnen ACT 2616  Melbourne Vic 8010  Queen Victoria Building NSW 1230 

Tel: 02 6219 5555  Tel: 03 9963 6800  Tel: 02 9334 7700, 1800 226 667 

Fax: 02 6219 5200  Fax: 03 9963 6899  Fax: 02 9334 7799 

TTY: 03 9963 6948 

Contents 

EXECUTIVE SUMMARY 1

Introduction to the trial  2

Project background  3

Execution of the trial   3

Results   4

Conclusions   5

CHAPTER 1: INTRODUCTION 8

Terms of reference  8

Previous technical studies  10

How filtering technologies operate  12

Identification techniques  12

Blocking techniques  14

Outline of the report   16

CHAPTER 2: PROJECT BACKGROUND 17

Appointment of test agency  17

Selection of filter products   18

Compilation of test data  20

Selection of test site  22

CHAPTER 3: EXECUTION OF THE TRIAL 23

Performance   23

Operation of an ISP’s network  23 

Network performance metrics  25 

Test network and hardware 27 

Test methodology 29 

Calculation of results 34 

Effectiveness  35

Test network and hardware 35 

Test methodology 36 

Calculation of results 37 

Scope  37

Adaptability   38

CHAPTER 4: RESULTS 39

Performance  39

Effectiveness   43

Scope   44

Adaptability   45

Summary   46

CHAPTER 5: CONCLUSIONS 47

Performance  47

Effectiveness   49

Scope   51

Adaptability   51

Current state­of­the­art   52

APPENDICES 54

Appendix A: The Ministerial Direction  54

Appendix B: The tiered hierarchy of ISPs  56

Appendix C: Types of network filter products not assessed   58

Filter products targeting illegal content only   58

Enterprise­level filter products   59

Appendix D: Specifications of the hardware used.   60

Network Performance Test   60

Accuracy Test   60

Appendix E: Baseline network performance characteristics of the test network   61

Appendix F: Individual product performance   62

Alpha  62

Beta   63

Gamma  64

Delta  65

Theta   66

Omega  67

GLOSSARY 69

BIBLIOGRAPHY 78

Executive summary

Executive summary 

This report has been prepared by the Australian Communications Media Authority (ACMA) in response to a ministerial direction received in June 2007 to conduct closed environment testing of internet service provider (ISP)­level internet content filters. The purpose of the trial was to assess the current maturity of commercial filtering products that are suitable for deployment by internet service providers. The direction is at Appendix A. 

A detailed assessment of the ACMA considers that, under the conditions created for the trial, the 

state-of-the-art of ISP-level state of ISP­level filtering technology has significantly advanced, 

filtering technology is at and stands in contrast with the state of this technology evidenced in 

pages 52—53 the previous trial of filter products commissioned by NetAlert Ltd in 

2005. The main indicators of the increasing maturity of ISP­level filtering technology are: 

actual deployments of filter products by ISPs in other countries. 

The one area which showed little sign of advance was reflected by the absence in this trial, for the most part, of any capability of filtering content carried via non–web protocols. 

The findings of this report and the assessment of the state­of­the­art 

of ISP­level filter products reflect testing in a controlled laboratory environment. In particular, the testing simulated a Tier 3 network (the lowest level of the ISP network hierarchy); different results might be observed in a real０world Tier 3 network or in networks at 

Executive summary

higher levels in the ISP network hierarchy. This is due to variations 

in architecture, including hardware used, size and complexity of the network and traffic demands. 

Introduction to the trial

The purpose of the trial was to assess the capability of available technology to filter illegal or inappropriate content at ISP­level and advances in filtering technology since the previous trial in 2005.  The report commences with definitions of the four criteria against which the capability of ISP­level filtering technologies was assessed: 

performance; 

and block illegal content, content that may be inappropriate for minors and innocuous content; 

internet traffic; and 

different levels of blocking according to the preferences of the user. 

ACMA was not asked, as part of the trial, to assess the capability of ISP­level filtering technologies that filter only illegal content. 

ACMA was also not asked to investigate the balance of costs and benefits associated with implementing ISP­level filtering, including: 

capital and operating costs associated with implementing filter 

products; 

costs associated with any upgrading of an ISP’s network to 

address performance degradation associated with a particular filter product; and 

the nature and implications of the implementation of ISP­level 

filtering for ISPs’ customers. 

ACMA also did not assess other matters that may be of relevance to the efficacy of ISP­level filters in a real­world context, such as; 

the extent to which a filter can be circumvented; and  the ease with which it is installed, deployed and implemented. 

Chapter 1 summarises the findings of previous technical studies of filtering for the Australian Government and concludes with an explanation of the different types of filtering techniques. 

Executive summary

The method of compiling the

Category 1, 2 and 3 lists of

URLs is described at pages

20—22

Details of the methodology

used in testing performance

are provided at pages 29—

35

Details of the methodology

used in testing effectiveness

are provided at pages 35—

37

Project background

Chapter 2 describes the selection of six filter products for testing, following a public call for expressions of interest from filter vendors. 

In accordance with the ministerial direction, the trial was required to test the capability of filter products to distinguish between illegal, inappropriate and innocuous content. To test this capability, three lists of URLs were created as test data: 

1 Category 1 was intended to test the extent to which the selected filter products blocked content on the ACMA prohibited 

content list. 

2 Category 2 was intended to test the extent to which the selected filter products underblock, by allowing access to content that may be regarded as harmful or inappropriate for children but is not illegal. 

3 Category 3 was intended to test the extent to which filter products overblock by blocking access to content that may be regarded as innocuous. 

Execution of the trial

Chapter 3 describes how an isolated purpose­built network was established to test performance, simulating both the function of the internet as a source of content and the function of end users 

requesting content. The test network was analogous to a Tier 3 ISP. Testing of the effect on network performance of each filter product involved measuring: 

baseline performance of the test network with no filter installed;  performance of the test network with each filter connected, in 

turn, but with no active filtering occurring; and 

performance of the test network with each filter connected, in 

turn and actively filtering. 

Three indices representing the performance of each filter product were calculated from the results of these tests. 

Testing of effectiveness involved measuring: 

the effectiveness of a filter in blocking content corresponding to 

Categories 1 and 2—that is, content that was intended to be blocked; and 

the effectiveness of a filter in distinguishing content from 

Category 3—that is, content that was not intended to be blocked. 

Executive summary

Details of the performance

results are at pages 39—43

Details of the effectiveness

results are at pages 43—44

Two indices representing the effectiveness of each filter product were calculated from the results of these tests. 

Chapter 3 concludes by describing the methodology used to assess the scope and adaptability, which involved an expert review of product documentation and interviews with suppliers of the products 

to identify specific features of each product. 

Results

Chapter 4 sets out the measurements from the quantitative performance and effectiveness tests for the filter products and lists the capabilities of the filter products with for scope and adaptability. For the performance test, the percentage results showing the degree 

of degradation introduced by a filter connected to the test network but not actively filtering (where a low figure indicates a lesser degree 

of performance degradation) were: 

below 30 per cent for all products; and  below 10 per cent for five of the six products. 

The percentage results showing the degree of degradation introduced 

by a filter connected to the test network and actively filtering (where 

a low figure again indicates a lesser degree of performance degradation) were: 

above 0.88 for all products; and  0.94 or above for three products. 

The results showing the degree of success in not blocking content 

corresponding to each of the URLs listed in the Category 3 list (where figures fall in the range of 0 to 1 and a low figure indicates a greater degree of success in not blocking content that was intended to 

be blocked) were: 

below 0.08 for all products; and  below 0.03 for four products. 

Executive summary

Details of the scope results

are at pages 44—45

Details of the adaptability

results are at pages 45—46

A comparison of the results

for performance in this trial

with those of the previous

trial is at pages 47—49

Each of the filter products is able to block traffic entirely across a wide range of non­web protocols, such as instant messaging and peer­to­peer protocols. However, a capability to identify illegal content and content that may be regarded as inappropriate carried via such protocols was not found, excepting: 

Conclusions

The specific findings for performance and effectiveness in this trial are substantively different to those of the previous trial. 

The previous trial reported that, when filters were connected to the test network and actively filtering, performance degradation ranged from 75 per cent to a very high 98 per cent between the best­and-worst performing filter products. In the current trial, the 

corresponding performance degradation varied across a greater range—from a very low two per cent to 87 per cent between the best-and­worst performing filter products.  

to moderate levels of degradation in network performance.  

The median network degradation of the tested filters significantly dropped indicating a significant improvement in network 

performance in the current trial compared with that of the 

Executive summary

A comparison of the results

for accuracy in this trial

with those of the previous

trial is at pages 49—51

previous trial. ACMA considers that this improvement in the performance of filters tested in the current trial compared with the previous trial represents a profound advance in ISP­level filtering technology. 

The previous trial reported a difference in the level of successful blocking (that is, the proportion of content that should have been blocked that was actually blocked) between the least and the most accurate filter products in the range 70 to 100 per cent. The corresponding levels measured in the current trial varied across a smaller range, between 88 and 97 per cent, with most achieving over 

92 per cent. The median rate of successful blocking was improved from the previous trial. 

Executive summary

An assessment of the ability

of ISP-level filters to control

non-web content is at pages

44—45

Despite the general nature of advances in ISP­level filtering technology between the current trial and the previous trial, most filters are not presently able to identify illegal content and content that may be regarded as inappropriate that is carried via the majority 

of non­web protocols, although development work by filter vendors 

is underway in this area. This is despite developments in the use of internet technologies that have led to increased use of non­web protocols such as instant messaging and file­sharing.1 

1

 See Chapter 2 of Australian Communications and Media Authority, Developments in Internet Filtering Technologies

and other Measures for Promoting Online Safety, February 2008. 

or their customers The purposes served by evaluating ISP-level filtering products against these criteria are set out The chapter goes on to outline the previous Australian Government technical studies on internet filtering and presents a summary of their respective findings and concludes by providing an overview of the contents of each of the following chapters

This report sets out the results of a study into the maturity of products for filtering internet content that are suitable for deployment by internet service providers (ISPs). The study was informed via a technical, laboratory­based trial of a sample of commercial filter products available to ISPs, 

conducted in the first half of 2008. The study was undertaken at the direction of the former 

Minister for Communications, Information Technology and the Arts for the purpose of assessing: 

the capacity of available technology suitable for deployment by ISPs to filter internet content 

that is illegal and inappropriate for minors which consumers may access through their internet connection; and 

filtering products satisfactorily perform their essential role ０ that is, successfully identifying and preventing the delivery of illegal internet content and internet content that is inappropriate for children, while permitting innocuous internet content. 

The scope criterion is intended to indicate the ability of ISP­level filtering products to identify and 

block illegal and inappropriate internet content that is transmitted and delivered across the internet using non­web protocols (for example, instant messaging, file transfers) in addition to web 

content. 

The adaptability criterion is intended to indicate whether ISP­level filtering products can offer a 

range of filtering options that enable a filtered service supplied to an ISP’s customers to be tailored 

to meet specific requirements of the ISP or of the customer, as opposed to a ‘one­size fits all’ filtering solution. 

Accordingly, the assessment of ISP­level filtering products against these four criteria seeks to update knowledge about the overall maturity of ISP­level filters, not to identify a ‘best buy’ 

product. 

There are some other matters that may also be relevant to the efficacy of a filter in a real­world context, but which were outside the terms of reference and not assessed by ACMA. These include the following. 

Filters may vary in their resistance to circumvention. Table 1 illustrates some common methods 

of how filters can be circumvented and how these methods may apply to both PC０based filters and ISP０level filters. 

Administrator passwords Can be circumvented Cannot be circumvented

Boot disks Can be circumvented Cannot be circumvented

Translation software Moderate probability of circumvention

Search engine caching Low probability of circumvention

Additional domain names Low probability of circumvention

Table 1: Common methods of circumventing filters

Unlike PC０based filters, which are open, ISP０level filters lie on the internal network of an ISP which is generally firewalled off from public access and are therefore less open to attack. 

Filters may also vary in the administrative complexity of installation, deployment and 

implementation. Factors such as the compatibility of existing hardware in the ISP’s network in 

Chapter 1: Introduction

which the product is installed, the availability of skilled personnel and degree of change that such a device brings into a network make it impossible to assess in a closed trial of this nature. 

Previous technical studies

This report is the latest in a series of Australian Government technical studies of internet content filtering, which are summarised below. 

BLOCKING CONTENT ON THE INTERNET: A TECHNICAL PERSPECTIVE, CSIRO, JUNE 1998

Commissioned by the National Office for the Information Economy, this report examined the technical aspects of the internet that allow particular content which has already been identified as illegal or offensive to be blocked, particularly by ISPs and content hosts. The report explored the technical issues associated with different methods of blocking content, as well as some non-

The primary observation of the report was that almost all the products were effective in blocking undesirable content, but all blocked some portion of desirable content. 

INTERNET CONTENT FILTERING, OVUM, APRIL 2003

The major observations of the study were that no major technological developments had occurred since the commencement of the online content co­regulatory scheme in 2000 and that ISPs who had adopted filtering had seen a limited impact on throughput. It also noted, however, that the costs associated with such an implementation at the ISP­level made it unattractive for ISPs. 

BROADBAND PERFORMANCE DEGRADATION AND SOME EFFECTS ON THE USER EXPERIENCE, RMIT IT TESTLAB, APRIL 2005

Commissioned by NetAlert Ltd to provide a quantitative analysis of the performance impact of applying server０based internet content filtering applications and appliances to an internet feed in both live and controlled environments, this technical trial provided information on: 

the extent of degradation of internet access speed and performance; 

the accuracy of filtering; and  

the effect of filtering on the user experience when using broadband internet services. 

RMIT IT TestLab encountered difficulties in finding products for the trial that were specifically designed for ISP０level filtering; consequently, all the products tested were designed for enterprise­level content filtering but had the capability of being deployed in an ISP’s network. 

only one in six users noticed any degradation in network performance, but this degradation was 

regarded as minor and acceptable; and 

all users reported a measure of over­blocking. 

The present report updates the body of evidence about the state０of０the０art of ISP­level filtering technologies in 2008, recognising both the possible developments in filtering technologies and the changes in internet use since the reports described above. 

Chapter 1: Introduction

Index-based filtering is the process of permitting or blocking access to web pages on the basis of 

their inclusion on a list (or index) of web resources. Such filtering can be based on ‘whitelists’ (exclusively permitting specific content while blocking all other content) or ‘blacklists’ 

(exclusively denying specific content while permitting all other content). Indexes may be 

developed manually, by human searches and analysis of content, by category indexes (most 

commercial filter vendors provide a database of URLs classified by the nature of the content) or automatically by analysis­based filtering, as discussed next. Figure 1 illustrates the architecture of index­based filtering. 

Figure 1: Index-based filtering process

Internet

Step 1: User requests

content

Step 3: Web server returns content

Step 2: Request for content is forwarded to web server Web server hosting

requested content

Filter Step 5: If content

is assessed as inappropriate, it content is

otherwise it is delivered

Figure 2: Analysis-based filtering process

3

 A packet is a formatted block of data that can be transmitted over a network. It includes both header information and  the content to be delivered.  

DNS poisoning (also referred to as DNS tampering) involves changing the information returned to 

a particular user within their DNS server4 when responding to a query of a blocked domain. Users attempting to request blocked websites will not be directed to the correct IP address.  

Caching web proxies are used in networks to acquire web content from a host on behalf of a user 

and deliver it to the user’s web browser. They provide a perceived increase in web browsing speeds and reduce bandwidth usage by holding copies of frequently requested material so that a request does not need to be made to the content host every time a user in the network wants to view the content. The same technology can be used to precisely block the content that is deemed to 

be inappropriate, usually on the basis of URL. The content retrieved and stored in the local cache 

is inspected and classified offline. Based on the classification of the cached content, proxies may then modify the communications between user and content host, usually to block requests for content hosted at a URL on a blacklist, often replacing the returned content with an ‘Access 

Denied’ (or similar) message to filter out inappropriate sections.5 

Some filters use port blocking to close ports through which particular data is transferred. Different 

classes of programs or services on a computer use different ports to send and receive data. For example, some email programs use port 110, while web traffic is received through port 80 by default. By blocking the ports that various programs use to access the internet, filters aim to 

prevent use of those programs to access content on the internet.  

Used primarily with analysis­based filtering, pass-by filtering allows a requested web page to load 

and marks it for later analysis. The page will later be added to the filter vendor’s index of 

categorised material and therefore blocked, where appropriate, for users who subscribe to a filtered service. This means there is no delay to the user in accessing requested material, but that 

inappropriate content may be viewed by a user once.  

Used primarily with analysis­based filtering, pass-through filtering is often referred to as 

‘proxying’. Delivery of a requested website is not permitted until analysis of its content is 

complete, introducing a certain amount of delay6 that depends on the processing power of the hardware on which the filter software is installed.  

Most commercial filter products employ both index-based filtering and analysis-based filtering This is to provide a robust filtering solution by minimising the respective

limitations of each approach; that is, filtering that relies exclusively on an index may not appropriately deal with newly created internet content and filtering that relies exclusively

on analysis may consume an excessive amount of processing resources on the computer or other hardware on which it operates

Chapter 1: Introduction

Outline of the report

The remainder of this report is structured as follows. 

Chapter 2 describes the preparation for the trial, including the appointment of a test agency, the selection of a sample of ISP­level filtering products for testing and the compilation of test data comprising URLs linking to content that is illegal, inappropriate for children or innocuous. 

Chapter 3 sets out the manner in which the testing of the sample of ISP­level filtering products was conducted. The methodologies used for testing the performance and effectiveness of the sample filter products are described, including the design of the test network, the test procedures and the derivation of several measures of filter performance and effectiveness. Chapter 3 also describes the manner in which the scope and adaptability of the sample filter products was assessed. 

Chapter 4 provides the detailed results for the sample filter products in relation to performance, effectiveness, scope and adaptability. 

art of ISP­level filtering technologies, both by reference to the capabilities of the sample of filters tested in this trial and by comparison with the previous trial undertaken by NetAlert Ltd in 2005. Chapter 5 concludes with observations suggesting the standard that presently available ISP­level filters are capable of achieving. 

Chapter 2 describes the initial steps taken in establishing the trial, which began with the

appointment of Enex TestLab to conduct the trial It describes the process by which a sample of six filter products was selected for testing, outlines the range of filtering techniques employed by the selected filters and provides an overview of the characteristics of each of the filters Also covered

in the chapter is the process of creating test data for the trial, in the form of three separate indexes

of URLs The first index, which corresponded to the ACMA prohibited content list, was for the purpose of assessing the extent to which the selected filters successfully block content on this list; the second index was for the purpose of assessing the extent to which the filters fail to identify content that is intended to be blocked; and the third index was for the purpose of assessing the extent to which filters block content that is intended to be accessible The chapter concludes with a description of the selection and establishment of a test facility

Appointment of test agency

ACMA selected Enex TestLab to conduct the trial following a competitive tender process. 

The tender process commenced with the issue of a request for tender, accompanied by the posting 

of a notification on the AusTender website7, publication of an advertisement in The Australian and 

issuing of a media release by ACMA drawing attention to the request for tender. Three tender bids were received in response to the request for tender. These were subjected to a careful and thorough evaluation in order to select the company that best met the following criteria specified in the 

Chapter 2: Project background

Enex TestLab is an established provider of information and communications technology testing and benchmarking services. 

Selection of filter products

In order to conduct the trial, it was necessary to acquire a selection of filter products that exhibited 

a broad spectrum of available internet filtering technologies.  

Enex TestLab placed an advertisement in the IT section of The Australian seeking filter vendors 

interested in participating in the trial. Vendors were asked to submit completed expressions of interest packages for each individual product that they proposed to offer for testing. Twenty­eight expressions of interest, representing 26 products, were received from vendors (two products were each represented by two expressions of interest from separate vendors). 

The expressions of interest were considered by an evaluation panel established by Enex TestLab. The purpose of the evaluation was to arrive at a selection of six products, where the selection: 

functionality generally resides in the facilities of the filter vendor itself; hence there is no way to test such solutions in a closed environment.  

of, or establish VPN through which they retrieve their internet content. Such a service cannot be tested in a closed  environment. 

filtering technique, but use a combination of two or more methodologies. Specifically, most 

commercial filtering products and all of the selected filter products, employ a combination of index­based filtering and analysis­based filtering. 

Similarly, none of the selected products only targeted illegal content. This is because the testing required under the terms of reference involved assessing the accuracy of the filters in blocking inappropriate content, which comprises a significantly broader range of material than illegal 

content. However, it is possible to configure all of the selected products to filter illegal content only, using a blacklist such as ACMA’s prohibited content list and allow access to all other types 

of content. The characteristics of illegal content filtering are discussed further in Appendix C. 

In accordance with non­disclosure agreements with the suppliers of the selected filter products, names of the individual products have been withheld; the products have instead been represented 

by the Greek letters Alpha, Beta, Gamma, Delta, Theta and Omega. 

9

 This requirement was to eliminate any suggestion by software vendors that their products were installed on 

incorrectly configured hardware. 

Chapter 2: Project background

Product Beta is a software solution. It is installed within the core network. The vendor also offers 

an option where the application is sold as an appliance. For the purpose of this trial, the vendor provided the software solution pre­installed on its own hardware. The product employs index­based filtering, analysis­based filtering, packet filtering, port blocking, pass­by filtering and pass­through filtering. 

Product Gamma is a software solution. It is installed within the core network. The vendor 

provided its product pre­installed on its own hardware. The product employs index­based filtering, analysis­based filtering, packet filtering, DNS poisoning, port blocking and pass­by filtering. 

Product Delta is a software solution. It is placed within the core network. The vendor also offers 

an option where the application is sold as an appliance. For the purpose of this trial, the vendor provided the software solution pre­installed on its own hardware. The product employs index­based filtering, analysis­based filtering, packet filtering, DNS filtering, caching web proxies, port blocking and pass­by filtering. 

Product Theta is a hardware appliance. It is a gateway device. The product employs index­based 

needed to be compiled as test data. 

Under the National Classification Code, content for films is classified in categories G ０ General, 

PG ０ Parental Guidance, M ０ Mature, MA15+ ０ Mature Accompanied, R18+ ０ Restricted, 

X18+ ０ Restricted and RC Refused Classification. The National Classification Code provides a nationally uniform and well­defined standard for rating content and is the standard that is applied 

under Schedule 7 of the Broadcasting Services Act 1992 to classification of internet and mobile 

content. 

The Category 1 index of URLs was created from the ACMA prohibited content list. In accordance 

with Schedule 5 to the Broadcasting Services Act 1992, this list contains URLs that link to internet 

content hosted outside Australia for ACMA is satisfied is prohibited or potentially prohibited. Prohibited and potentially prohibited content is defined in clauses 20 and 21 of Schedule 7 to the 

Broadcasting Services Act 1992 and may include content in the range MA15+ to RC. The ACMA 

prohibited content list was provided to Enex TestLab, which checked whether each URL was still live. ACMA approved the Category 1 index, containing 1000 URLs, before it was employed in the trial. 

For Categories 2 and 3, a distinction needed to be made between inappropriate and innocuous content. The National Classification Code provides a helpful distinction between content that is legally restricted—MA15+ through to X18+—and that which is not—G through to M. 

Accordingly, for the purpose of the testing, this distinction was used to separate inappropriate content from innocuous content. In a real­world application, filters may allow more granular distinctions to be made. 

The Category 2 index of URLs was drawn from an existing database of URLs held by Enex 

TestLab. The content from this list of URLs was intended to be rated in the range from MA15+ to X18+. A proportion of content rated as strong M, which was regarded as close to the MA15+ classification, was also allowed in this category. To verify that the content assembled in this list fell into this range, ACMA checked the range of content accessed via the URLs. ACMA approved the Category 2 index, containing 933 URLs, before it was employed in the trial. 

The Category 3 index of URLs was also drawn from an existing database of URLs held by Enex TestLab. The content from this list of URLs was intended to be rated in the range from G to M. To verify that the content assembled in this list fell into this range, ACMA checked the range of 

10

 The ACMA prohibited content list is a list of URLs that have been reported by internet users to ACMA and have  been categorised by ACMA’s Content Assessment team as prohibited content. This list includes content rated RC  1(b)—Child Pornography—as well as other content rated RC, X18+ and R18+. 

Chapter 2: Project background

content accessed via a sample of the URLs. ACMA approved the Category 3 index, containing 

1997 URLs, before it was employed in the trial. 

Selection of test site

As set out in the minister’s direction, the trial testing was required to be conducted in Tasmania. For this purpose, Enex TestLab secured the premises of the Telstra Broadband eLab in 

Launceston. 

Under the agreement between Enex TestLab and Telstra for use of the Telstra Broadband eLab, neither Telstra nor its employees nor any of its affiliates were permitted to have any input or influence on the trial conducted within these premises. 

of the test network used for measurement of performance and effectiveness is then described

For measuring performance, this chapter describes how, in order to assess the extent to which a filter

introduces any changes to the throughput of an ISP’s network, the trial collected data to enable

comparison of the performance of the test network with no filter installed, with each filter product installed but not actually filtering content (passive mode) and with each filter product actively filtering content (active mode)

For measuring effectiveness, this chapter describes how, in order to assess the accuracy of a filter in

identifying and blocking content from categories 1 and 2—while similarly identifying but allowing access to content from category 3—the trial collected data on whether each URL in the three indexes described in the previous chapter was correctly identified by each filter product, either for blocking or permitting access to the corresponding content

For measuring scope and adaptability, this chapter describes how, in order to evaluate the capabilities

of filters in filtering non-web traffic and in customising filtering policies in accordance with the

specific requirements of an ISP or one of its customers, an expert review captured details of various capabilities of the selected filter products

PERFORMANCE

Evaluating the performance impact of filters meant determining the extent to which the operation 

of a particular filter product in the test network introduced degradation in network performance.  Before indicating how performance impact was measured in the trial, it is necessary to describe the typical architecture of an ISP’s network in order to appreciate where and how performance of the network can be affected. 

Operation of an ISP’s network

Figure 3 illustrates a typical layout for the network of an ISP offering ADSL broadband services (it is not an actual representation of any particular ISP’s architecture). 

The links among the various network elements are shown using lines of varying widths and 

colours. The thickness of each line is representative of the bandwidth of the link represented by it. Links within the ISP’s internal network are of higher bandwidths (and are accordingly shown with 

Chapter 3: Execution of the trial

lines of greater thickness) than the link between the end user and the local exchange digital 

subscriber line aggregation module (DSLAM). 

Legend: Line Speeds

OC48: 2.488Gbps OC12: 622Mbps OC3: 155Mbps

Core router

Local exchange DSLAM

Content filter Database server

Typical ISP internal network architecture End user

(usually co-located in a central exchange)

‘Access’ network

Figure 3: A typical ISP's architecture from the ISP to the end user

There are usually multiple users (in the order of hundreds to a few thousand) connected to a local exchange and multiple local exchanges (in the order of tens to a few hundred) connected to a central exchange. ISP networks are typically designed in this manner as it offers a scalable and cost­effective solution for the network demand likely to be generated by end users. 

In this typical ISP network, an end user on an ADSL connection is connected via their local 

exchange11 DSLAM, through their central exchange multiplexer12, to their ISP, which then routes their traffic back and forth to the internet via an internet gateway. The bandwidth of the network links decreases as one gets further away from the internet gateway.  

Figure 3 illustrates that the segment that is the ISP’s core network constitutes the ‘prime13’ 

network, as connections among its respective network elements are assigned a high bandwidth. By contrast, the segment between the end user and the local exchange DSLAM constitutes the 

‘access14’ network. The peak network throughput to the end user is limited to the subscriber’s bandwidth, which is usually no more than a few megabits per second. 

Consequently, a slowdown in performance on the access network does not necessarily indicate any end­to­end congestion in the network. For example, such degradation in network performance may 

13

 In networking terms, this is often referred to as the ‘fast’ network. 

14

 In networking terms, this is often referred to as the ‘slow’ network. 

is a significantly larger amount of bandwidth on the ‘prime’ network than what the access network can demand. In the example shown in Figure 3, the bandwidth of the access network is 1.5 

megabits per second, whereas that of the prime network is 622 megabits per second—over 400 times greater. As a result, the access network representing the segment between the ISP and the end user has little bearing on the effect of an ISP­level filter on the overall ISP scalability.  

Measurements conducted on the prime network provide a quantitative gauge of the effect on network performance of a filter within the ISP’s core network. These measured quantities express the number of transactions per second and the data rate within the network (measured in megabits per second) that the ISP’s network is capable of supporting. The effect of a filter on an ISP’s network is best reflected by the performance seen within the prime network. The measurements conducted in this trial focus on this area. 

The network architecture applicable for ISPs offering connections other than ADSL—for example, dial­up, cable, satellite or mobile connections to the internet—is broadly similar to that described above, although the bandwidth available on the access network may differ significantly. 

Network performance metrics

throughput—the actual speed at which data will be transferred from one point on the network 

to another at a particular time16; it can be regarded as the rate at which ‘useful’ data is 

transferred. 

Users rarely experience throughput higher than 80 per cent of the rated bandwidth.17 This is due to the inherent design of network protocols – the set of rules by which data is transferred across networks. Various network protocols are in common use; for example, the IEEE 802.3 standard for Ethernet and ATM.18 Irrespective of the standard of protocol that is used, data is split into 

‘packets’ before transmitting. Each packet is assembled into a pre­defined format (as specified in the protocol), called a ‘frame’, before being transmitted. A frame typically contains elements such 

assuming that the 4MB MP3 file is divided into 1500­byte packets and there are no retransmits20 

as a result of packet loss in transmission. In reality, however, data communications without 

retransmissions rarely occur. If such a transmission required a single instance of retransmission, the efficiency would fall to 49.11 per cent. Routing devices attempt to balance overhead and number of retransmissions by adapting packet sizes, in order to obtain optimum network 

performance. As a result, the theoretical efficiency is rarely obtained. 

As a result of the balancing of overhead and number of retransmissions, the throughput of 

networks increases with increasing network load until the network reaches a state of saturation; that is, the network is carrying as much traffic as its theoretical bandwidth. For Ethernet networks, this is about 80 per cent of the available bandwidth. Beyond this point, as network load increases, the network efficiency begins to plateau. This characteristic is illustrated in Figure 5. Similar characteristics have also been observed for other protocols.  

19

 Tannenbaum, Andrew S. (2002), Computer Networks 4th Edition, Prentice Hall 

20

 A retransmit is where the same packet is transmitted more than once to overcome a scenario where the original  packet may have been lost when initially transmitted. It is analogous to repeating oneself in a conversation when  the recipient fails to interpret one’s statements the first time. 

predictable nature; for example, streaming media. This is because routing and switching devices require less time to determine the optimum packet size. The performance of Ethernet traffic 

degrades as traffic becomes increasingly ‘bursty’; that is, where packet size becomes random.22 Traffic generated by internet chat and games, where packet sizes vary without a predictable 

pattern, are examples of such traffic. 

Network throughput is also measured in the number of transactions per second. A transaction is  defined as a complete cycle of data interexchange. For the purpose of this trial, a transaction starts 

with the initiation of a web request and ends when the requested web content is delivered.  

Test network and hardware

An isolated test network to simulate an ISP’s network was built to observe the effect of each filter product on network performance.  

The network architecture is shown in Figure 6. The network architecture seen here is analogous to 

a Tier 3 ISP; that is, an ISP that purchases outbound transport from other networks in order to reach the internet (see Appendix B for details). 

21

 The percentage load applied is a measure of the network demand placed on a network as a percentage of the total  bandwidth available. An array of 20 machines each demanding 10Mbps equates to 200Mbps; such an array would  place a network with an available bandwidth of 100Mbps under a load of 200 per cent. 

22

 Mazraani, T.Y.; Parulkar, G.M. (1992), Performance analysis of the Ethernet under conditions of bursty traffic,

Global Telecommunications Conference, 1992. Conference Record, GLOBECOM Communication for Global  Users., IEEE Volume , Issue , 6­9 Dec 1992 Page(s):592 ­ 596 vol.1 

controls WebBench tests;

compiles and collects test results

Vendor supplied content filter

filters internet content

Content return path Content Request Path

Traffic statistics information Gigabit ethernet

DNS

performs IP address lookup

Figure 6: Test network for evaluating network performance of internet content filters

static web content in the form of HTML documents; and 

images complementing web content in the form of GIF and JPEG files. 

The web server acted as a target host for web requests generated by the array of client machines (described below), individually processing the requests and delivering the resultant content back to the requesting client. 

Simulating end users

To measure the effect of individual filters on network performance, the function of end users requesting content was simulated using a tool called WebBench 5.0, a benchmarking and testing software program developed by VeriTest that measures the performance of web servers and 

networks under different load conditions. 23 

WebBench 5.0 operates using a client­server architecture. The controller manages the execution of the tests and compiles the statistics collected by the client machines at the end of a test cycle. This machine was connected to an array of client machines that generated the web requests. The client load­generation array comprised six machines, each running the WebBench client software in 

23 

Chapter 3: Execution of the trial

order to generate web requests to the web server within the controlled environment. Since the environment used was an isolated environment, the total network bandwidth remained in a 

controlled and stable state. 

The entire network was connected and switched using a gigabit switch. 

An array of automated load­generating clients, as described above, is a standard method of 

generating web requests within a closed environment for testing of this nature. A similar load­generation array was used in the pervious trial conducted for NetAlert Ltd in 2005. 

The hardware specifications for the web server, the WebBench controller and the WebBench clients are listed in Appendix D. 

Test methodology

The performance testing involved a series of web requests generated by the client machines under the direction of the controller. 

The controller instructed the clients to generate a defined sequence of transactions consisting of web requests varying in volume, as well as the interval at which they were generated.  

6 The filter responded by either blocking or permitting content through to the requesting client machine. 

7 The client machine terminated the web request cycle. 

Web server

simulates internet content

WebBench controller

controls WebBench tests;

compiles and collects test results

Vendor supplied content filter

filters internet content

Step 2: Web request passed

Step 5: Web server responded

and returned requested content

through filter

Step 6: Filter responds by either

blocking or permitting content through to the requesting client machine

Step 7: Client terminated the web

request cycle

Figure 7: Sequence of generation of a transaction

A mix is defined as a specified number of clients simulating a specified number of end users generating a specified number of transactions at a specified interval.  

1 Upon receiving a message from the controller with a specified mix, each client initiated a web request directed at the web server. This generated web request was the beginning of a transaction. The initiating client continued to track elapsed time before receiving a 

corresponding response back from the web server, which in turn signified the end of the transaction. 

2 The elapsed time for the transaction was recorded by the client machine before it 

proceeded to the subsequent transaction.  

3 At the end of a sequence of mixes, the data recorded for all the transactions by each of the clients was transmitted back to the controller. 

It was necessary to structure the testing in this manner to bring the network into saturation. This is discussed below. 

The controller compiled the statistics captured by each client to compute the number of 

transactions per second occurring within the network over the sequence of mixes and the 

throughput exhibited during each sequence. 

The presence of the controller machine remained a constant throughout all the tests. No content was exchanged between the client machines and the controller between the beginning and the end 

of a test cycle. Hence, the controller had no influence on the test results. 

For the purpose of conducting this performance test, it was necessary to bring the network into a state of bandwidth saturation. In a network in which spare bandwidth exists, any network latency caused by a client machine demanding additional bandwidth would go unnoticed.  

However, in a bandwidth­saturated network, demands for additional bandwidth lead to packet loss and therefore increased network latency and degradation in overall throughput. 

Each client machine running the WebBench client was capable of simulating multiple end users. Preliminary network load tests conducted on the test network revealed that the network reached a state of bandwidth saturation when six end users were simultaneously generating web requests on the one gigabit per second switched network. This corresponds to a network saturation occurring at 

a little in excess of 9,244 transactions per second (the threshold for network saturation) which in turn corresponds to a throughput a little in excess of 55,807,057 bytes per second or 425 megabits per second24 (the throughput threshold for network saturation). A detailed graph of the network characteristics is shown in Appendix E. 

Having established the point of network saturation, the network performance test required 

measurements to be taken with the network in a prolonged state of saturation. It was seen that simulating 30 end users sufficed to generate and maintain this persistent state of network 

saturation (that is, where the network is carrying as much traffic as its bandwidth permits).  

24

 Conversion: 1 byte = 8 bits (b); 1kilobit (kb) = 1,024 bits; 1 Megabit (Mb) = 1,048,576 bits. 

Chapter 3: Execution of the trial

The clients in the load­generation array were accordingly programmed to simulate 30 end users.  

Table 3: WebBench test sequence

The WebBench controller coordinated all the mixes in a test sequence while keeping the client machines synchronised. Each mix of the WebBench test sequence defined: 

Number of clients—the number of physical client machines used in the test; 

End users per client—the number of users that each physical client machine simulated; and  Mix duration—the duration for which each mix of the test executed; for example, mix #6 

consisted of six clients simulating two end users each for a total of twelve end users over a period of 90 seconds. 

These clients ran on a one Gbps network, generating up to 30 end users. This would scale to up to 20,000 end users each on a 1.5 Mbps connection, which is the typical end user bandwidth of 

ADSL connections. 

The evaluation of the effect on network performance of each internet content filter involved three steps: 

1 Establishing a baseline with no filter connected to the network. 

2 Recording network performance with the filter connected to the network but with no active content filtering occurring. 

3 Recording network performance with the filter connected to the network and actively filtering requested content. 

Chapter 3: Execution of the trial

Establishing a baseline

Web server

simulates internet content

WebBench controller

controls WebBench tests;

compiles and collects test results

Content return path Content Request Path

Traffic statistics information Gigabit ethernet

DNS

performs IP address lookup

Figure 8: Network diagram for network performance test while establishing a baseline

The network configuration used to establish a baseline is illustrated in Figure 8. This test network architecture replicated an ISP without a filter installed. A set of simulations was executed on this network using WebBench. The traffic generation parameters in Table 3 were used to generate web requests. The network performance statistics were collected by the controller at the end of each test cycle. To minimise any statistical variances, this set of simulations was executed five times. A statistical average of the number of transactions per second and the network throughput observed was calculated and provided the baseline. 

Network performance with a filter installed with no active filtering occurring

A filter product is a network element. Every additional network element introduced into a network may introduce a change to the performance of a network. This second step involved evaluating the effect on network performance of a network filter being introduced into the network without actively filtering content. Figure 9 shows the network configuration used for this set of tests; Figure 6 differs from Figure 5 in that a filter is installed between the gigabit switch and the web server. 

This test served two purposes: 

1 It provided a quantitative measure of the change in the transactions per second and throughput that occurred in the network for the filter product being tested. 

2 It provided a reference point for the subsequent measurement of the difference in network performance observed when the filter actively filters content (as distinct from when it is 

installed into a network as a transparent network element and is not active).