TREVBUS stands for Transmission Repeaters Enabling Virtually Bandwidth-Unlimited Streaming.
The final software system will enable a community of streaming content broadcasters to stream audio and video at zero marginal cost. The system operates on a broadband metropolitan-area network or a LAN. For zero marginal cost, it relies upon there being no traffic cost for each node's incoming or outgoing data.
The present problem with a broadband metropolitan network is that each user's outgoing bandwidth is a fraction of the incoming bandwidth. This is the motivation for TREVBUS. The solution is for cooperating nodes to repeat each other's content when requested. Thus, much like "phone trees" many more clients can receive streaming content than the outgoing bandwidth of any one residential connection would allow. Figure 1 illustrates.
The purpose of this Software Requirements Specification is to define how users of TREVBUS will install, configure and use TREVBUS.
The software to be produced will be a package that will install both content director and repeater software on a node. Associated documentation will also be available.
Quoted from Project Plan:
Broadband metropolitan networking offers the potential for communities to communicate without recourse to existing mainstream media, which is monolithic and not sufficiently diverse or participatory.
The ACT's broadband metropolitan network will allow video to be delivered to set-top boxes by local organisations. The costs of doing so appear very high for the foreseeable future.
As an alternative, I propose to design and write a software system to enable individuals to cooperatively and scalably deliver multiple streams of video and audio across TransACT at zero marginal cost using low cost Internet Protocol connections.
Such a system could create community of content providers which, in order to expand its audience, must attract participants in order to grow its multicasting capacity. A virtuous circle of growth would be created, in contrast to existing closed and often cliquey media organisations.
Aims and objectives of the project
The explicit aims of the project are:
- To define the specifications of a dynamically scalable system to send, to multiple locations on a network, streams of IP data from a computer connected to the network by using multiple cooperating computers, also connected to the network, as repeaters.
- To research, determine the feasibility of, and design, such a system. To determine if the system should be implemented as a variation or extension of another free software project. To determine which aspects of the system can be completed within the technical constraints of the network and time constraints of the project.
- To implement a scalable working system and test it on a small scale.
- To document the system for participants and users and create a website to tell people about it.
- To address some organisational issues such as legal issues for participants in such a system.
- Overall, to provide the basis for a community of content broadcasters to assist each other to deliver high-bandwidth streaming content at low cost over a broadband metropolitan network, specifically, TransACT.
It is not proposed to determine if the system successfully facilitates a growing community of content providers, since this will take longer than the project's timeframe. Such a large-scale test may occur after the project's completion.
The SRS covers the interaction of users with TREVBUS to the necessary extent, but not necessarily the complete interaction of TREVBUS nodes with each other.
This SRS will, in this first version, not delve in to the algorithm by which the optimal tree or chain structure of streamed content repeaters will established.
This SRS first gives an outline of various aspects of the TREVBUS system.
It then delves in to these aspects in more detail where necessary.
TREVBUS will be developed for the Free Software operating system, Linux. Directors and Repeaters will require well-known GNU components.
TREVBUS will rely upon TCP/IP, HTTP and protocols specific to the streaming of content, RTSP, RTP, RTCP and SDP. The TREVBUS implementation of some of these protocols shall have extra functionality to enable TREVBUS to operate more effectively. Where such functionality is used, the protocol shall be referred to as 'adapted' (e.g. adapted RTSP).
The software developed will run on TREVBUS nodes, and shall act as a repeater and, if configured as such, as a director as well.
TREVBUS does not have system interfaces with any other computer system.
User interfaces can be dealt with in three parts: Interfaces for broadcasters, participants and users.
Users can be dealt with briefly. Users shall access streamed video and audio content by accessing a URL by means of a web browser. The URL shall be provided in a hyperlink which may be clicked.
The client's browser shall then take whatever action is normal for whatever stream type is being received. The first implementation of TREVBUS will be implemented to conform with QuickTime technology from Apple. The director shall send the client a .mov file.
The stream is received via the Real-Time Transport Protocol so the browser should launch media player software which is interchangeable with, or is, QuickTime Player. The RTP stream may then be received over either UDP or TCP after being established by means of RTSP and SDP.
For participants, the following interfaces are required:
The broadcaster's identity (identified by director)
The identity of the content stream or an aspect of the stream's metadata, such as its bandwidth or content rating.
The IP address of the immediate sender (not necessarily the director).
The IP address of the immediate recipient (not necessarily the client). This criteria also applies to the director.
The jurisdictions the content is only intended for.
The previous two criteria are to prevent the repeater (or director) incurring traffic costs for sending data to or receiving data from nodes outside the LAN or broadband metropolitan network which TREVBUS operates in. They could be specified in much the same way as the ALLOW and DENY directives in apache configuration files.
For broadcasters, the following additional interface is required:
There must also be interfaces to allow broadcasters to review the performance of TREVBUS , both at their node and in general. Apart from the current configuration at their node, data to be provided shall be the time of commencement and duration of each stream reception at a client and the chain of repeaters from which this stream was received. Any change in path for a client shall be recorded as a new record.
From this data it should be possible to reconstruct the tree or chain of repeaters for any given content stream at any given time.
The TREVBUS director and repeater software shall reside upon Linux. The software will receive content from other software via Linux constructs such as sockets. Therefore TREVBUS can be developed independently of hardware, with the exception of the hardware being capable of handling streams of data with large bandwidth.
The client's hardware must also be up to the task.
Upon a request from a client, the director shall request an RTSP/RTP connection from the content generator. The director software shall establish the connection to the generator and transmit the stream via TREVBUS.
The director shall maintain a log file for each execution of a content stream process. The content generator shall be able to query this log if it has access to the director computer's filesystem and perhaps change the content generation in some way as a result.
The repeater shall operate independently of other software on the repeater node. The repeater node shall maintain a log of all stream pathways it repeats and including the full path from director to each of the clients. Each time this path changes, including the addition or loss of a client or a dynamic rearrangement of the path shall be recorded as the end of the stream and its re-transmission. There are many ways to represent this data at any given moment, let alone as time passes.
The user's software interface must ensure their browser acts correctly when it first receives the content stream.
Communication interfaces are largely explored in the previous part. Any greater detail would involve close examination of the interaction between trevbus nodes.
Content arriving at the client shall be RTP with a RTSP control connection.
A content generator node shall need sufficient memory, primary and secondary, to deal with large quantities of data.
A TREVBUS process will require relatively little memory. There will be no caching of streamed data as this introduces needless complexity to the system. A fast network, fast memory access and a fast processor are critical. A processor equivalent in power to a Pentium II at 400MHz with 128Mb shall be more than sufficient.
For all components of the software, there is a single mode of operation. Prior to this there is installation, and joining TREVBUS. During the single mode of operation, configuration changes shall take effect when the affected software is restarted. This means that making configuration changes requires the loss of services being provided by the affected software. A prior warning that repeater service will be lost is sent to all affected directors. If a director is reconfigured, content generator software will need to detect such warnings as they are written to the log files.
Upon execution TREVBUS automatically determines the node's IP address, name and associated details for the purposes of acting as a repeater. In order to operate as a director, the broadcaster must specify the generator which the director will request the presentation from.
When a director/repeater node joins TREVBUS, it must be informed of existing TREVBUS repeater nodes' IP addresses. From this information, it uses queries of these nodes to determine all repeater nodes available.
Once operational, a TREVBUS director software shall await HTTP requests from a first client for the content stream it is responsible for.
The director serves clients through repeaters. It shall determine a repeater by which the streamed content requested shall be relayed. It shall reply to the HTTP request from the client with a .mov file. The director shall then await an RTSP connection from the Repeater, so that it may send the stream to it, possibly via other repeaters.
When a request for a content stream is received by the Director from the Repeater, the director shall request a RTSP connection from the streaming content generator.
Subsequent client requests for already transmitted streams shall be treated similarly except that the content stream from the generator shall be reused for each repeater added to the tree.
When a repeater ceases a connection to the director, the director may have no more repeaters for that content stream. In this case, the director shall then issue a TEARDOWN request via RTSP to the content generator.
Once operational, the repeater software shall await connections from clients. If the requested content stream is not already being relayed through this repeater, the repeater shall contact the director and request the stream. The director may choose to redirect the repeater's request to another repeater, in which case the repeater shall request the content stream from this other repeater.
Because a client cannot be redirected once it has been allocated to a repeater, the director must check the repeater is willing to serve before assigning the client to it.
When a client ceases a connection to a repeater, the repeater may not have any clients for that stream. The repeater shall then cease the connection with the source of the stream, be that another repeater or the director, by means of a RTSP TEARDOWN request.
The approach has the following advantages:
It prevents TREVBUS being manipulated to launch distributed Denial of Service attacks. For a stream to be directed at a client, it must be requested by that client. The client must establish an RTSP connection with a repeater, which can only succeed if the client is willing to acknowledge the request. The repeater then requests content from the director. That is, one cannot initiate an attack without spoofing a TCP connection from the target client's IP address.
It has the advantage of simplicity, because a repeater requests a stream from another repeater as if it were a client. All the while, the director maintains oversight and coordinates the connections.
Mechanisms will be developed for dynamic re-arrangement of the repeater tree during transmission.
A client is a person with a standard IP connection to the broadband metropolitan network who accesses streaming audio or video content by means of an HTTP browser. They need only have basic internet skills. The user will however, need to have the QuickTime plugin installed on their computer, which may require a privileged user.
A content broadcaster and a participant will both need to be able to install and start up TREVBUS.
A participant will have a basic understanding of the TREVBUS system. They will understand concepts such as IP addresses. They will be able to independently install TREVBUS on their system. They will be able to edit textual configuration files, though the initial version of TREVBUS doesn't require this. These skills are required so that updates to the system can be propagated promptly. This is important in a cooperative system.
A content broadcaster will have practical skills in assembling the software and hardware components required to generate and stream content to the director software. These skills are required because content generation is complicated. They will have a good understanding of the workings of TREVBUS and how to configure TREVBUS as a director for various situations. At present, configuring TREVBUS to be a director requires editing and recompiling the software.
Participants and broadcasters will have documentation with an emphasis on howtos to enable ``learning by doing''.
TREVBUS is developed primarily for TransACT. TREVBUS is therefore constrained by TransACT's connection and pricing arrangements. The greatest constraint is the outgoing bandwidth of a standard residential internet connection. This is limited to 128kbps for the most basic viable connection. However, this constraint is the very motivation for this software.
The maximum effective bandwidth of TREVBUS is limited by the sum of the outgoing bandwidth of all the its nodes, minus the bandwidth used to repeat streams between the nodes. This inevitably means not all broadcasters will get large audiences all the time. Though a comparison with a pyramid scheme, where certain individuals succeed at the expense of others is not fair - any broadcaster can become the head of a tree, if their content is popular enough.
There are many potential legal constraints for TREVBUS. Refer to the thesis for a discussion.
Security is an important aspect of TREVBUS. The system shall not be open to misuse for the purposes of distributed Denial of Service attacks and suchlike. In general, IP addresses are used to confirm the identity of nodes.
Audit functions will require that extensive logs be kept of the operation of each TREVBUS node. This is for the purposes of debugging, optimisation and the detection of misuse. The operation of TREVBUS is often complicated, so the logs should be carefully designed to be comprehensible. Content generator scripts may also require access to these logs in order that CPU time not be wasted generating content that is not being transmitted.
Where possible, TREVBUS will fail informatively. This is so that users are willing to try TREVBUS again soon and do not come to see TREVBUS as unreliable.
TransACT's technical set up may prevent aspects of the system being implemented effectively. Since the system is in itself a workaround while community use of high bandwidth set-top boxes remain too costly, having to work around more technical constraints should not be taken as a defeat. A change that would could cause problems is reliance on non-static IP addresses. However, for on-network traffic, IP addresses will be static, so this problem is unlikely to arise.
TransACT could change its pricing or connection policies in a manner that makes the finished system non-viable or makes the implementation and testing too expensive, such as charges per megabyte for traffic costs on the network. Such changes are unlikely. Changes that may cause problems would be a downgrading in the outgoing bandwidth for 1 or 2 Mbit/s connections. If the outgoing bandwidth for such connections is below 70kbits/s, useful participation in the system becomes available only to those with the fastest residential connections. Thus the worth of the project is diminished.
It is assumed that QuickTime Player and Darwin Streaming Server comply with RTSP and RTP and SDP standards, at least to the minimum standards.
It is assumed that any proprietary components of the QuickTime implementations of RTSP, RTP and SDP are either hidden from TREVBUS, are published or are easily reverse-engineered.
Features that may be delayed until future versions of TREVBUS are:
The specific requirements for TREVBUS will be organised by stimulus
The only direct user interfaces in TREVBUS will be in the administration of the repeater by a participants and the director by a broadcaster.
Details of such user interfaces are not a priority at present.
All interactions with hardware are through abstraction layers such as IP and and the operating system.
The software shall interface only GNU/Linux and possibly Perl or similar scripting language.
The external communications interface of the director shall be that of a repeater in addition to a HTTP client.
The TREVBUS HTTP responses shall be generated by a cgi-bin script running under an HTTP server or else generated by a stand-alone program.
In either case the program shall respond to a HTTP GET request for a presentation of the form:
with the .mov file as appropriate, in standard HTTP form including a Content-type: field:
HTTP/1.1 200 OK\r Server: TREVBUS 1.0 for Linux\r Content-type: video/quicktime\r Content-length: %d\r Accept-ranges: bytes\r Connection: close\r \r\n rtsptext\r\n rtsp://repeater_IP:rtsp_port/trevbus/director_IP:rtsp_port/presentation\r\n \r\n
The .mov file starts with rtsptext which tells QuickTime Player to access the RTSP address given and connect to the repeater which the director has designated for this player.
The only external communications interface of a repeater is with the upstream and downstream nodes. The interactions with the client software (at the leaf nodes of the repeater tree) shall be exactly as if the client were communicating directly with the generator. Any variation from this will not be of consequence, apart from problems introduced by time delays.
The director, upon receiving an HTTP GET request shall examine the request to determine if it is responsible for the specified URL. If not, it shall respond as per HTTP.
If the director is responsible, it shall send back the response in the previous section, with a RTSP URL decided upon at execution-time. The URL's location shall be that of a TREVBUS repeater and RTSP port number, and the object requested shall begin with /trevbus/ and then specify the name of the director, its RTSP port number and the presentation name.
The HTTP connection shall then close.
These requirements are too detailed to delve in to here. In summary, the communications requirements are that the repeater and director (which may well be the same program) be transparent to both client (QuickTime Player) and content generator (Darwin Streaming Server).
TREVBUS should compile on GNU/Linux without configuration.
There is no configuration requirement for operating TREVBUS as a repeater.
In order to operate TREVBUS as a director, changes should be made to a configuration file, specifying the:
There are default values for these ports, however it is best to specify them when starting trevbus.
As a director, TREVBUS also needs to know the locations of repeaters it will send connections to. This is best accomplished by specifying them in the configuration file. This is a delayed feature. Presently the settings are specified in the file main/config.c. TREVBUS must be recompiled for the changes to take effect. Documentation supplied with the software shall explain what to do.
TREVBUS must establish new presentation sessions promptly. It must stream data so as not to introduce jitter. The latency of the presentation must not exceed 1 second more than if the client connected directly to the generator.
The design is constrained by QuickTime player. It would be best if QuickTime player could handle RTSP REDIRECT. If it could, then the repeater tree could be dynamically re-arranged more effectively.
TREVBUS shall comply with RTSP, RTP, and SDP to the extent which QuickTime player and Darwin Streaming Server do. Additionally TREVBUS shall adapt RTSP to allow information about and control of the repeater tree to be handled by the director. These adaptations shall not be visible outside TREVBUS.
TREVBUS shall ensure that repeaters that clients are to directed to have capacity to accept clients. This will ensure the reliability of the client-repeater connection.
TREVBUS shall have mechanisms by which repeaters that have lost contact with upstream or downstream connections may contact the director to have the repeater tree repaired.
TREVBUS will not be exploitable as a basis for Distributed Denial-Of-Service attacks. This is to be mainly achieved by ensuring that repeaters send RTP (streaming content) packets only to nodes from which RTCP packets are being received.
Maintainability is achieved with this document and the SDD.
TREVBUS shall be written for Linux but shall be portable to any Unix platform (with foundation components, perhaps also Perl) with a couple of days' work.
This document was generated using the LaTeX2HTML translator Version 98.1p1 release (March 2nd, 1998)
Copyright © 1993, 1994, 1995, 1996, 1997, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -split 0 -no_subdir -no_navigation SRS.tex.
The translation was initiated by Alexander Gray Pollard on 2001-06-28