Draft of Consumer Broadband Monitoring Feasibility
1.0 Initial Requirements
Since central monitoring does not scale effectively, a home device is required. The device needs to be cheap, available worldwide and amenable to complete software customisation. It should preferably be a device that already exists in the home of the pilot audience and, if added to the user's installation, it has to be transparent to the rest of the home network.
The home device needs to work in conjunction with a subset of the existing Test Traffic Measurement (TTM) infrastructure. The system should not introduce significant processing load within the TTM node software nor should it cause architectural software changes. No new TTM nodes should be deployed as part of this effort, unless specifically purchased by a pilot participant.
Anonymised time-stamped raw measurement data should be centrally available for research.
User and provider privacy needs to be enforced. This means that users can only see their own data and that providers have no access to other providers' customer measurements. To mitigate service providers' concerns with respect to competitive comparisons - when and if such a need arises - public summary data should consist of anonymous coarse-grained scoring similar to that used by Band-X [1] for grading transit. It is desirable to plan for such capability from the start.
Pilot deployment preference should be given to those service providers that are willing to relocate, or newly locate a TTM node within a densely populated customer access network.
2.0 Measurements
All measurements are between the home device and a designated TTM node located within the user's service provider's access network.
The periodic measurements are: packet loss, delay and jitter. Bandwidth measurement should only be available on demand because of TTM node side load.
3.0 Non Measurements
This system does not and should not measure inter-domain performance. The test end points comprise the consumer's home and one or more TTM nodes placed within that consumer's service provider network, at a location determined by the service provider. No measurements will be taken between home devices nor to TTM nodes not expressly assigned by the service provider.
4.0 Approach
Few devices meet the above requirements. The LinkSys WRTG54 [2] however, makes for an easy choice. It is a wireless router/bridge, made by Cisco, with a market price of under US$50. Its software is open [3], runs Linux and has an extensible soft probe and network management package [4] already running on it.
The choice of the LinkSys device should not be construed as a decision to use it for production deployment, if and when approved.
5.0 Deliverables
As a first step, a prototype of the system will be built, in order to demonstrate the acceptance and usefulness of such a system. All measurements shall conform to relevant IETF IPPM specifications, where applicable. The study needs to address the following issues:
-
demonstrate build and software update process on the LinkSys device
-
implement one measurement and the corresponding provisioning, database and data distribution
-
quantify LinkSys clock stability
-
report on practical deployment and operational issues such as installation, upgrades, etc.
The hardware platform for these measurements is an ADSL router/access point. Measurement software will be added to this platform, however, the device should continue to act as an ADSL router. Before the full system is designed, a prototype will be built to show that this is possible. The prototype will also be used to get an idea of the deployment issues. The proposed hardware platform is a cheap device that will typically be run in a home environment, with large variations in room temperature. We will check if the hardware is stable enough platform for these kind of measurements. The RIPE NCC shall provide a calibration methodology for qualifying and selecting the measurement platform.
Optional specification and software deliverables shall comprise:
-
TTM node scalability testing. The RIPE NCC shall provide a test methodology and plan.
-
Web browser based user interface for provisioning, on-demand bandwidth test, threshold e-mail alarm and 30 day trends
The RIPE NCC will publish a report on the development of the prototype.
6.0 Schedule
Building a prototype is expected to take a few months of work. Its timeline is as follows:
10/2005 - Verify user requirements during RIPE 51 Test Traffic Working Group
06/2006 - Project start
09/2006 - Prototype is presented at the RIPE 53 Test Traffic Working Group.
09/2006 - Discussion on the next steps, including deployment. This will result in a new policy proposal.
7.0 Cost
One Full Time Employee (FTE) to build the prototype.
8.0 Volunteer Advisory Board
Laurent Bernard - France Telecom, FR
Rickard Dahlstrand - Consultant, SE
Luca Deri - University of Pisa, IT
Niall O'Reilly - University College Dublin, IE
Rainer Rudiger - Teleport Consulting and System Management, AT
Ad Spelt - KPN, NL
9.0 Acknowledgements
Luca Deri - University of Pisa
Henk Uijterwaal - RIPE NCC
Rene Wilhelm - RIPE NCC