Overlays like the MBONE, 6BONE and ABONE tend to require manual configuration and do limited routing to maintain their connectivity in the face of failures. How could we design a self-organizing overlay, so that as nodes were turned on they merged with the existing topology in an appropriate way? What are simple, scalable and efficient membership rules that ensure the overlay remains connected? And what is a reasonable definition of "appropriate", since all nodes of an overlay typically have connectivity with all other nodes via the Internet? We could infer the underlying Internet topology and use this to guide overlay topology so that added costs are minimized. Develop a self-organization scheme in the context of ANTS and the ABONE.
With the exploding usage of domain names and DNS-based approached for Web server load balancing (round robin and short timeouts), it's reasonable to assume that the load on the DNS has increased. The DNS is also at a turning point with the change in its regulatory body. By looking at real traces, let's find out how the DNS is actually being used and when it's failing.
How often are Internet routes unavailable and why? What can we do to find this out? It should be possible to correlate public BGP dumps taken at different locations to infer what fraction of the Internet can't reach what other fraction at a given time.
The measurement results in UW's Detour paper (Sigcomm99) suggest that carefully chosen overlay routes can provide better performance than native Internet routes. To what extent is this true? It's not possible to know without trying the overlay routes because sending traffic along those routes will influence the measurements. Let's build a simple test system, deploy it at a dozen sites, and find out.
Pacing regulates the flow of traffic and reduces its burstiness. Intuitively, this has the potential to make better use of network buffers, yet preliminary simulations have not demonstrated this advantage. How does packet pacing help or hurt network and TCP performance? Use Amit's simulations as a starting point to strengthen an understanding of the effects of pacing, both in networks with and without RED gateways. A good first step would be to start from fundamentals and see how traffic from simple LIMD models combines to cause loss.
Blue is a different approach to queue management that claims to fix problems with Red. Rather than using increases in average queue length as an indication of congestion, Blue focuses on average utilization by observing queue overflow and underflow. This may have advantages in situations where there are many flows. For what kinds of networks does Blue live up to its claims? Evaluate Red versus Blue by simulation.
Consider using active networks for end-system protocols such as TCP. This would be useful because TCP evolution is restricted by deployment considerations, and has the advantage that no routers need to be modified. The interface design portion of the problem should also be tractable because the operation of TCP is well understood. However, a potential problem is that the TCP you write might not implement congestion control properly and hose the network. Luckily, equation-based congestion control and Savage's recent work that mitigates the effects of misbehaving receivers provide a safe playground with a small trusted base. Use these techniques to implement a simple active network system that allows users to implement their own application level transports.
Active networks aim to allow untrusted code to be safely run in the infrastructure. Local resource containment is relatively easy to achieve. But how do we ensure that programs such as multicast don't cause excessive bandwidth consumption across many nodes when they are run because they are poorly written? For example, packets can inflict a fair amount of damage if they bounce between two (or more) nodes. How do we make progress here by restricting program forms or providing simple distributed checks? Evaluate the alternatives in the context of ANTS.
Internet religion is to use soft-state to build robust systems. Distributed systems religion is to use hard state (along with replication and consensus) to build highly available systems. Who's right? Work through a design example, such as a routing or resource reservation, to understand the tradeoffs.
Routing is a distributed computation in which one faulty node can disrupt the entire network. How can we build safe routing systems so that faults (whether malicious or not) are contained in their effects? Explore the alternatives. Note that traditional authentication is of limited use here.
When there are many short flows, as is common with Web traffic, TCP congestion control is not effective. To handle the short flow problem, a number of schemes have been suggested to combine the congestion function of related flows so that the many short flows act as a single larger flow. Design and evaluate via simulation a "congestion gateway" scheme, where congestion information is shared between multiple related flows from different hosts.
Packet pair is a technique for estimating the bottleneck bandwidth of a network path. This information is useful to prevent a flow from overrunning the bottleneck. Design and implement a receiver-based packet pair scheme in the context of TCP.