Pricing the Internet

The Competitions

Summary

Think you can do better that the strategies you have seen so far? Prove it! Will your strategies be suckers that are exploited by others? Will they be ruthless and cutthroat? Or will they cooperate with others to achieve the best result?

You can write strategies for Users and just see how they work. Or you can write competitor strategies, designed to achieve a specific objective like transferring a file at minimum cost, and grade yours against everyone else's. We will be running a series of competitions based on different objectives.

You are not restricted to writing flow control strategies. The simulation architecture is briefly described, to indicate what sort of flexibility is available.

Current Competitions

A competition consists of a goal, a description of the type of strategy that tries to attain the goal, and rules for scoring. In some cases we describe what sort of simulation environment the competition will be run in, and suggest some starting points for strategies.

Writing your own strategies

You can write strategies which inherit from FlowControlStrategy, as described in The Model. Or you can write a strategy which inherits from some other standard interface.

You can also write strategies which attempt to achieve a set goal. For each objective, there will be a corresponding Strategy class which you should inherit from.

For example, in the FileSpeed competition, the objective is to transmit a file of given size in the shortest time possible, subject to a limited budget. For this, you should inherit from FileSpeed.FileSpeedStrategy. The details are much the same as for SingleFlow.FlowControlStrategy.


uk.ac.cam.statslab.pricing.components.FileSpeed.FileSpeedStrategy
public class FileSpeed.FileSpeedStrategy
  {
  double abstract updateRate(FileSpeed.MarkInfo lastMarks); // override this
  }
uk.ac.cam.statslab.pricing.components.FileSpeed.MarkInfo
public class FileSpeed.MarkInfo
  {
  int getMarks(); // number of marked packets received last timestep
  int getDropped(); // estimate of number of dropped packets last timestep
  double getCost(); // getMarks()+k*getDropped(), where k is set by experimenter
  double getMoneyLeft();
  int getTransmitLeft();
  }
You should read the rules for each competition to find out the relevant interface.

Testing your classes

You can try out your strategies in the simulator. Download it as described in Demonstration. You need to compile your class
javac MyStrategy.java
and insert a line into the classes.txt file in directory Simulator/
# add a line to classes.txt for each class you want loaded
MyStrategy
Your strategies can now be loaded into the simulator as usual.

Standard interfaces

Many strategies fit into the framework of SingleFlow, which privides a single route along which to send packets. These strategies should inherit from SingleFlow.StreamControlStrategy and override the execute method

uk.ac.cam.statslab.pricing.components.SingleFlow.StreamControlStrategy
public class SingleFlow
  {
  public static class StreamControlStrategy
    {
    public abstract void execute(PacketList in, PacketList out); // override this
    }
  ...
  }
If you don't want to worry about keeping track of dropped packets, you can inherit from FlowControlStrategy and override the updateRate method

uk.ac.cam.statslab.pricing.components.FlowControlStrategy
public class FlowControlStrategy extends SingleFlow.StreamControlStrategy
  {
  public void execute(PacketList in, PacketList out)
    // work out how many packets were dropped and marked, store in lastMarks, call updateRate
  public abstract double updateRate(MarkInfo lastMarks); // override this
  ...
  public class MarkInfo
    {
    public double getCost()
    public int getMarks()
    public int getDropped() ...
    }
  }

Simulator Architecture

There are three fundamental classes: Resource, UserTemplate and User. The first two have already been described. A UserTemplate is a template for Users. For example, when you add a SingleFlow.FlowControlStrategy, you are really asking the UserTemplate SingleFlow to create a User with that strategy.

Many of these classes are made up of other classes. A QueueResource is an example of a Resource, and it contains a QueueResource.QueueMarkingStrategy. When you add to the simulation a class which is made up of secondary classes, you are prompted to specify which those secondary classes should be.

Another very useful example is SingleFlow. This is a UserTemplate which also has a Route. Whenever you add a SingleFlow.FlowControlStrategy to the UserTemplate, it creates a new User made out of the Route and the FlowControlStrategy.

Editing properties

Many classes in the simulator have properties you can edit. This is achieved by writing a pair of methods such as
public int getQuantity();
public void setQuantity(int i);
These methods must be public and have matching names and parameters, although the type need not be int - it can even be a class.

This lets you write your own classes made up out of secondard classes. Just create a pair of methods inspecting and setting the secondary class. The only restriction is that the secondard class must have a public constructor taking no arguments.

Once the experimenter okays the parameters, if your class has a method

public void done()
it is called.

Viewing Statistics

Many of the classes you can deal with implement ObservableNumbersClass. For those classes, you can write a method
public NumbersObserved[] getObservableNumbers()
and any of the quantities you return will be listed in the various logs and views available.

Many classes also have toString() and stateToString() methods which describe the state of an object.

Documentation

Interfaces for all of these classes can be found in the Simulator/docs/ directory. Here are references for some of the classes mentioned here: UserTemplate, Resource, User, SingleFlow, Flow, ObservableNumbersClass.

Damon Wischik D.J.Wischik@statslab.cam.ac.uk