TCP/IP is a widely used network control protocol, providing reliable, end-to-end, flow-controlled transmission of data over IP. Much research has been done concerning its behaviour under congestion conditions, and many fixes have been performed, to try and make TCP stable in such situations. These fixes usually involve trading off local performance of a given TCP stack, against the global network performance; non-compliant TCP stacks are considered ``rogue,'' and are often penalised. This tries to ensure that network bandwidth is fairly shared between users.

However, there are a variety of ways in which a compliant TCP stack may be made more aggressive. These range from causing the transmission window to increase artificially quickly, to multiplicatively backing off at a lower rate---relatively ``nice'' hacks---to having a high-bandwidth UDP stream transmitted prior to beginning a TCP transmission, causing existing TCP streams along the path to back off---a relatively ``nasty'' hack.

This project would involve implementing some or all of the above (and any others that are thought of), either in a simulator, such as NS, or in a suitable kernel (e.g. 4.4BSD, or Linux). The project would evaluate the effect of such behaviour on the throughput (or goodput) the hacked streams receive relative to the unhacked streams. It would also be nice to have some idea of how such hacks would be treated by the network, when such router disciplines as RED are enforced. A high degree of familiarity with TCP, along with competence in either C++ and Tcl (if, say, NS Home site; European Mirror is used), or C (if the implementation is performed ``for real'') is necessary.

NOTE: For those who are interested in doing a project related to NS, I strongly recommend you familiarise yourself with some of the source and documentation over the summer vacation. Use the on-line documentation and tutorial and the online CVS repository; I don't have enough Thor filespace to put a copy in (it's big...).

Special Resources: an account on the SRG linux boxes, with access to scratch space on a fast machine.

The Network Control and Management section of the NetOS group has developed and implemented an architecture known as The Tempest. This provides an environment for novel (ATM) network control and management systems by partitioning the resources in an ATM network, and by opening up control of the switches. Whilst this allows for novel control systems (or Control Architectures (CAs)), there is also a requirement that existing standard control systems run on the Tempest. For example, there is a basic implementation of a Q.2931 CA for the Tempest.

It would be very useful to have an implementation of TCP as a Tempest-aware control architecture. This would effectively be TCP/ATM, providing a TCP-like service to the OS, running directly over the ATM network, rather than over some IP-on-ATM system. This should be reasonable given the connection oriented nature of ATM and TCP; we already have a basic Bootstrap IP CA (``BICA''), over which facilities such as ARP can be provided.

This is a hard project, which might reasonably be considered research. Prior knowledge of ATM networks, TCP, and C++ programming are essential.

Network audio and video require reasonably high bandwidth and relatively low jitter (variation in delay). These requirements make it difficult to deliver high fidelity data directly from the network. However these media types may be encoded in a layered format; i.e. as a number of layers 1, 2, 3, ... n. The receiver may choose to decode any prefix of the sequence, obtaining increased fidelity in each case.

It is possible to distribute audio and video in a layered format where each of n layers is given a different multicast "channel". Receivers may then decide to receive the first k of these, and to decode (and render) the first j <= k of these in order to maintain real-time rates and/or to match the fidelity to the characteristics of the receiving terminal.

This project would choose or construct a layered encoding scheme for either video or audio (or both), and develop transmitting and receiving software. As a first step, broadcast on a local ethernet could be used in the place of multicast, although it would be nicer (and more valid) to use multiple networks and a "proper" multicast protocol.

Special Resources: an account on the SRG linux boxes.

Adapt a test-rig currently running on a real networking environment into one based upon a discrete event simulator (DES). This is an advanced project that will require prior knowledge of the C programming language.

During implemented you will be required to validate the simulation. You need to have shown a clear and justifiable decision process when approaching the project in order to optimise for both speed and to allow ease of integration into the existing environment.

Starting points will be offered for the DES construction and an outline of the approach required is available on request. You will have a free-hand at internal design and optimisation decisions.

You will be working within constraints of an existing code-base, much like any large software project, however while this project has a specific objective there is plenty of potential to distinguish yourself.

Special Resources: an account on the SRG boxes with access to a fast CPU and scratch space. Access to the cactus test-rig.

When analysing the behaviour of an end-system it is not always possible to instrument the system directly. In this project you will develop a system to system-call activity from NFS traces. Such systems have existed in the past, however NFS has had several recent upgrades (v3 and v4) and it is desirable that your interpretor will cope with these new traffic types. The final objective of your system is to postulate the system call (and thus the system activity) caused by a particular set of NFS calls.

Your work will make a substantial contribution to an existing project; while the tools for capturing and performing `first-level' interpretation of network trace data will be set, you will be required to develop and justify an approach to interpreting NFS information and establishing limiting cases of system level activity. While the actual approach you may use is open ended, previously approaches have been based upon Bayes theory and on purely statistical studies.

You will be assisted by prior knowledge of the C programming language and `unix' style operating systems, particularly interest in operating-system internals.

Special Resources: an account on the SRG linux boxes with access to pre-collected trace data and scratch space.

Implement a measurement-based estimator in a networking test environment. In recent years there have been published a number of approaches to measurement-based estimation. In this project you will need to implement an estimator in a previously existing test environment.

You will be required to design a strategy that is complimentary to both the data available to the measurement-based algorithm and to the real-time requirements of the implementation.

Framework implementation are available to follow however these prior implementations have their own drawbacks and you will be required to design to overcome those drawbacks where possible. Performance issues will inevitably arise.

Much like any large software project, you will be working within constraints of an existing code-base; however, there will be plenty of opportunity for you to show your abilities.

Special Resources: an account on the SRG linux boxes with access to a fast CPU and scratch space. Access to the cactus test-rig.