Task Descriptions

There need to be translated into a more detailed set of technical goals which are

• very specific
• technically achievable
• well enough defined that the success metrics can be defined as well as the likely content of the final project report.
• well enough defined such that the subsequent tasks can be carried out

This task encompasses all of the work needed to define the types of traffic we need to generate and use during the project, as well as the measurement systems required to characterise the network, and measure and demonstrate expected traffic behaviours.

A very important part of this task is to define the measurements and presentations (e.g. plots) which will be used to demonstrate that the project technical goals defined in task 1 have been achieved. I.e. the success metrics.

This task is divided into three parts:

• definition of the load traffic and the software and hardware is required to produce it;
• definition of the measurement systems required and specification of the software and hardware is required;
• production of necessary software and scripts for both of the above.

Task 3: Traffic Generation and Measurement: Equipment provision

This task is (perhaps artificially) separated from the previous task as it may involve benchmarking, hardware selection, negotiation of collaboration agreements and purchasing procedures.

All security implications are considered within this task.

Define aggregate traffic classes and policies to be defined. It is envisaged that a set of policies of increasing complexity are defined to administer the behaviour of the network and the experimental tests will provide a measure of their effectiveness, i.e. the defined policies can be measured against reality.

Much useful work can be done with the routing equipment in a limited laboratory environment, before connecting everything to the WAN. This makes sense anyway as the roll-out of some of the WAN connections appears to be likely to slip.

The work will include:

• Learning how to configure the routers for packet classification
• Configuration of policing
• Learning how to configure chosen PHBs
• Production of IOS templates for wider deployment.
• verification of measurement techniques
• creating and observing QoS behaviour,
• in particular “proof of principle” of project technical goal
• establising baseline throughput performance.

Tests devised for this purpose could form a useful basis for the more-complex WAN networks tests whilst also assisting in establishing a ‘learning curve’ for devising the router configurations.

The network configuration is defined here. It is shown as a set of increasingly complex configurations starting from basic IP connectivity to include elements of diffserv, MPLS and combinations thereof. In addition, the number of administrative domains increases from a simple “core” model to the “man - core -man” model.

In fact much of the work will have been done piecemeal during many of the previous tasks, and it may be in the end that there is little more to do.

The key point is that the focus of this task is different. Whereas previously the focus was equipment configuration, the focus of this task is a final output document.

Experience shows that it is only when writing such a document that missing measurements become apparent.

The work includes:

1. Revision of success metrics. The success metrics have been defined in task1. These are however likely to need revising in the light of experience to this point
2. Planning of a systematic set of e2e measurements corresponding to the above
3. Carrying out systematic set of measurements.
4. Scheduling regular technical presentation sessions (2 weekly ?) to present ongoing results to technical group for feedback and direction.
5. Evolving descriptive document and presentation.
6. Preparation of some form of publication.

Further work will be required to go from this point to the point of UKERNA having defined a “Scalable Managed Bandwidth Service” (i.e. replacement for old ATM pilot) as required of them by their SLA.

Work is required here to define what this means precisely over and above e2e Diffserv capability (for example it may only require providing and supporting nationally the associated set of traffic classifications, static (or possibly dynamic) SLAs , and policing mechanisms nationally).

This and the following task appear at the end as they can only rationally follow much of the work of the previous tasks. However this should not be misunderstood as diminishing their importance. Demonstration of “QoS” across international boundaries was a stated objective of the original proposal.

The generic task is

1. Identify end points in EU and US, in particular identify named people at the far ends who agree to be contacts for this project.
2. Identify which services can be extended, and identify all relevant connectivity issues.
3. Negotiate and lobby as appropriate to obtain in principle agreement for e2e connectivity where feasible.
4. Convert 3 into concrete series of steps to arrive at point where a set of tests (which should follow task 8) can be undertaken
5. Make measurement. It is suggested to programme

Of course the above does not contain much specific detail by the very nature of the task. In all probability most of the work is political. The details can only be apparent after following various lines of opportunity.

For example (but nothing below represents any firm agreement as yet)

1. Negotiations are already well underway with DANTE as part of the DataGRID/DataTAG projects for piloting of IP premium. On the face of it this matches well with the UKERNA programme of IP premium deployment. These lines must be followed to establish a coherent plan for connectivity to CERN and other European sites. Very likely INFN (IT) will be a key end point also.
2. We have already spoken with Les Cottrell at SLAC. Les has already performed QBSS tests which were presented at the GGF in Toronto. Les is very interested to extend these QBSS tests to MB-NG.
3. We have contacted Ian Foster, and have good contact with STARLIGHT and IWIRE in Chicago. Discussion of some scheme to extend QoS through to sites on IWIRE may be the next step.

Task Summary: The project proposal includes an objective to take network services up to the applications layer in some form. This task is to investigate and pilot suitable mechanisms for doing this.

The task is open ended, and may extend to any level of complexity (including dynamic allocation) as time and resources permit. It is not envisaged that applications would be able to set code points directly, rather that some indirection is provided where an application requests a service from some broker which itself has the right to negotiate with the netowrk.

It could also start from and directions to be proposed by collaboration members, and J.Crowcroft has already made suggestions in this direction.

It could use the GARA work which has been done in the Globus context (Volker Sandler – well known to CISCO). As understood so far this provides access via APIs to resource reservation, and was based around CISCO routers.

This task will define the high performance programme for MB-NG. It will specify the tests and experiments required to achieve high performance high throughput networking. It will also define suitable demonstrations of sustained data transfers over the network using various transport and application protocols.

This task will use the deliverables from Task 2 that define the test and background traffic patterns and generation methods, the corresponding specification work in this task is only to select those tests/measurements that are applicable. This task will also be driven by Task 7, in that the network configurations and operational policies for the high performance tests and demonstrations will be selected from those specified by Task 7. It is expected at all tests will be operated on a set of increasingly complex configurations and QoS policies starting from basic IP connectivity to include elements of diffserv, MPLS and combinations thereof.

This task is divided into several parts:

• Definition of the work required to investigate TCP/IP operation on high bandwidth links.
• Definition of the work required to investigate non-TCP/IP protocols.
• Specification of the data transfer tools to be tested.
• Organisation of the high performance demonstrations.