Student Projects 1999

Network Related

 Full TCP Implementation (NS) Network Related  1999  Student Projects  NetOS 

Contact: Richard Mortier  email

There is a network simulator, known as ``NS v2,'' commonly used for testing and prototyping new network control protocols, including nearly all TCP variants currently in use, along with multicast protocols, application level protocols, and so on. Unfortunately, most of the TCP implementations currently available for it are not faithful simulations of TCP, as the interest at the time was in TCP's congestion behaviour. For example, they typically fake out connection establishment and tear-down.

There is a more complete implementation (``FullTCP''), but this is very much under development; it still does not implement all of the TCP standard (such as RSTs). This project is to fully implement TCP for NS, following the TCP stack of your choice (e.g. 4.4BSD) as faithfully as possible. The project would be evaluated by the accuracy and efficiency of the implementation; NS is commonly used to simulate quite large networks, so efficiency is important. To attempt this project, a good understanding of TCP, C++, and Tcl (specifically ``OTcl'') may be considered essential.

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

 Pick'n'Mix TCP Hacks Network Related  1999  Student Projects  NetOS 

Contact: Richard Mortier  email

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 trys 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 is used), or C (if the implementation is performed ``for real'') is necessary.

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

 Pre-Fetching Web Cache Network Related  1999  Student Projects  NetOS 

Contact: Austin Donnelly  email

Whilst there are many web caches out in the big, wide world, they all rely on data that has already been accessed being accessed again. It would be nice if, rather than caching old data in this manner, one could have a cache which ``pre-fetched'' data, in a manner similar to many HD controllers. For example, when one visited a web-page, it might be worth beginning to download those pages linked to by that page, in order that the ``idle'' time, whilst the user is digesting the data, is not wasted. In practice one would have to be more clever than this, since some links may point at dead, or highly time-sensitive links, or there may simply be too many links to begin to download them in the background (from a network traffic point-of-view). Similarly, the interaction with the browser's cache (in terms of some of a child pages' links pointing to the same data as the parent's links) could be optimized. This type of cache could be implemented in either the client or the server.

 TCP Control Architecture Network Related  1999  Student Projects  NetOS 

Contact: Richard Mortier  email

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.

 Receiver-layered Multicast Network Related  1999  Student Projects  NetOS 

Contact: Steven Hand  email

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.

 Zero Copy Networking on Linux Network Related  1999  Student Projects  NetOS 

Contact: Steven Hand  email

In contemporary operating systems, networking stacks are typically implemented completely in the OS kernel. To handle swapping/paging, or to allow DMA, network data is received into kernel buffers. After some processing, the data is copied into the user buffer. In many cases, the processing itself can involve additional copies. Copies are also required in the case of network transmission.

These copies reduce performance (throughput) and increase latency. This project involves developing a scheme which allows the reception or transmission of network data directly to or from user space. A low-latency message passing interface could be implemented and tested to validate the scheme. An extension would attempt to implement UDP/IP (including fragmentation and reassembly) in user-space. Exceptional students could consider trying TCP/IP (which is tricky).

Special Resources: an account on the SRG linux boxes.

Note: this project is not as difficult as it might appear; there is substantial literature available on the subject, and a few prototype/reference implementations.

  Network Related  1999  Student Projects  NetOS
$Id: network.html,v 1.8 1999/10/05 17:07:26 rmm1002 Exp $