This project could either be carried out on the Nemesis operating system, taking advantage of its ability to provide applications with guarantees, or at a high priority on Linux.
Goals: The objective of this project is to implement an Ariel compliant Control Architectures. The Control Architecture would implement IP routing allowing switches not supporting IP routing to do so.
Requirements: Experience with, or at the very least, exposure to the C programming language would be a definite advantage. C++ skills would also assist in this project.
RSVP is a resource reservation system put forward by the Internet community to give quality of service guarantees to IP traffic streams.
Goals: The objective of this project is to implement an Ariel compliant Control Architectures. The Control Architecture would implement RSVP resource allocation.
Requirements: Experience with, or at the very least, exposure to the C programming language would be a definite advantage. C++ skills would also assist in this project. An understanding of the IP protocols and the RSVP protocol in particular will also be an advantage.
A related project, named Entropic, has developed a toolkit which incorporates statistical estimators which are capable of taking an input stream of data measurements, and computing the effective resource requirements of the traffic, for use in traffic control. In the Internet, which is currently dying a well deserved death due to uncontrolled overload, there is no mechanism for deciding whether or not to allow additional flows to use a particular router.
The US-UK Fat Pipe is an IP link of limited capacity linking Super Janet to the Continental US. At times over 30% of the traffic on this link has been observed to be retransmissions of packets dropped due to congestion. When this occurs, the network (link) melts down, in effect, and no useful work can be done.
This project will develop a simulation of a set of long-haul Internet links carrying IP; routers will use on-line estimation of the effective capacity remaining in the network to enable network overload control mechanisms to be used, thereby preventing network melt-down.
Goals: This project has the potential to develop algorithms for network control which could be of great use in the Internet. There is a distinct possibility of publishing the results, depending on the quality of your work.
Requirements: You need to have a good understanding of TCP/IP, and networks. You need to be able to program in C/C++, with confidence.
A set of laboratory machines used by the Compare project is equipped with a modified OSF/1 kernel containing instrumentation which allows the logging of selected events within the kernel (for details of this instrumentation see Project proposals ``Automatic Generation of Automata recognising Kernel Events'' and ``Real time analysis and display of kernel networking activity'').
The Measure project has, using the theory of large deviations, developed predictors which have application to resource allocation in such areas as network switching and process scheduling.
This project seeks to bring together existing techniques and infrastructures from both the Compare and Measure projects. Currently packets which cannot be immediately transmitted on a network interface are placed in a FIFO transmit queue, making it impossible to provide guarantees of bandwidth or bounds on latency. Such guarantees may be approached by manipulation of this queue, higher priority processes placing their packets higher in the queue, with the implication that spare capacity must be maintained for high priority arrivals. The degree of spare capacity required will vary dynamically, and it is hoped that this capacity may be adjusted by utilising the Measure predictors.
The implementation of this project will, therefore, involve modification of the existing instrumented kernel to recognise relevant events, to install real time analysis of these events and calculation of predictors of expected capacity requirements, and to manipulate interface transmit queues accordingly.
No modification of the kernel's scheduler will be required, should a packet for transmission not be admitted to a transmit queue the normal socket blocking mechanism being invoked. An existing modification to the system's scheduler may be utilised to provide a finer grained re-scheduling of blocked transmitting processes.
For the purposes of this project priority may be assigned by interface port number, certain `well known' ports such as those used by (say) ftp having priority over others such as telnet. Additionally a small suite of applications having differing QOS requirements and using other specified ports can be used for evaluation purposes.
Special resources: Access to project workstations, limited root access and additional file space for kernel building.
The objective of this project is to implement a CAC algorithm based on an exponentially weighted mean. Such an algorithm uses a combination of the current and previous line utilisation to predict the utilisation on the line in the future.
The laboratory has a test-rig for the testing of CAC algorithms. This test-rig enables calls of particular types and with nominated arrival characteristics to be sent into a variety of CAC algorithms. The behaviour of the algorithms can be compared on the basis of such characteristics as cell loss, line utilisation and call accept/reject ratios.
This algorithm will form another of a battery of such algorithms in the call test-rig. The test-rig can compare and contrast its behaviour with the behaviour of other CAC algorithms.
In addition to implementation of this algorithm, it is expected that a thorough comparison of this algorithm with others available will be undertaken. The test-rig has already been used comprehensively for this task and such a comparison has a well defined agenda.
Experience with, or at the very least, exposure to the C programming language would be a definite advantage.
The laboratory has developed a test environment for the evaluation and demonstration of CAC algorithms.
It is useful to be able to demonstrate the operating of algorithms and the operation of the Call Admission Control kit in use. Currently the demonstration environment has not evolved with the growth of the kit itself and as a result it can be difficult to show the output of the kit in a demonstration environment.
Goals: The objective is to allow a user (in the demonstration situation) to be able to select from a range of output available which algorithms for Call Admission Control to use and what sorts of traffic would be used. A further extension to this work would be to allow the dummying or simulation of the network whereupon the traffic generated and measurements taken are done as a real-time, simulated, task. The design of the demonstration environment must allow a developer to simply and easily extend the demonstration environment as the CAC evaluation kit is enhanced.
Requirements: Experience with, or at the very least, exposure to the C programming language would be a definite advantage. X environment programming skills, TCL/Tk skills or related skills in a related rapid prototyping language may also be of assistance.
A user interface that interacts with components of The Tempest(tm) world has already been developed, which shows graphically the presence of virtual networks and the connections created and deleted on behalf of each virtual network. In addition, some separate work has been done that has involved gathering statistics from a switch.
The project would be to develop a version of the user interface that visualises network resource usage, showing the proportion of allocated resource used by each virtual network, and the usage by all virtual networks as a proportion of available resource. A certain amount of code from the existing user interface as well as from the statistics-gathering work could be reused to create the new interface.
Once a basic user interface has been written, some experimentation on the optimal way to gather meaningful statistics for this task as well as different approaches to scheduling for "networks on demand" could be carried out.
It may be interesting to implement this protocol on Nemesis. Nemesis
machines could then exchange objects with handheld devices like PDAs, mobile
phones, etc. The protocol stack includes several layers, including the
physical signalling layer, the link access protocol (device discovery),
the link management protocol (multiplexing), a transport protocol (flow
control, segmentation and reassembly), and two high level protocols: one
providing emulation of serial and parallel ports, and the other providing
for typed exchange of objects.