Download 5 TASK

MB-NG Project Document
Document title
Definition of MB-NG Project tasks
Date:
29-Jul-2002
Status
Version 5.0 FINAL
Description
This document is intended to enumerate all of the work
required to achieve the project goals.
The work is split into suggested tasks and sub tasks, each with
the notion of a task leader.
The task leader, when agreed, would be responsible to ensure
the task moves forward according to the schedule, where
appropriate using other effort assigned to the task.
The schedule itself is presented in an associated MS-Project
Gantt chart.
Original Author
R.Tasker
Change Record
v1.0 Originally produced by R.Tasker in text form
v1.1: Modified by RT with input from J.Crowcroft, I.Bridge,
T.Chown, R.Hughes-Jones
v2.0 : Modified by P.Clarke, R.Hughes-Jones to put into
document format. Tasks rearranged and added to, particularly
the latter tasks.
V5.0 High Throughput Task added by RHJ
Introduction
This document is defines the tasks of the MB-NG project.
It should be read in conjunction with the Gantt chart which defines the associated
schedule Gantt Chart
Up to this point most of the time has been spent in trying to obtain a complete set of
task headings, with the aim of being able to assign task leaders, and create a baseline
schedule.
Details shown within each task may be inaccurate or inconsistent. The intention
would be for the task leaders to refine/redefine such details as the first part of the
execution each task Hence
The security task is a reference work from Tim Chown who has already agreed to
lead this.
1 TASK: Define detailed technical goals of project
Task Convenor: P.Clarke, J.Sharp
(I use the word convenor here to emphasise that this needs expertise from all
collaborators. JS and PC merely have the token to make sure this expertise is
used, and a document is produced).
Task description:
At this point the project goals are defined in a general way, i.e. “demonstrate end-toend QoS”, “demonstrate end-to-end scavenger service”. and “demonstrate the use of
e2e Qos by live Grid applications”
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
Deliverable:
[Document] Project technical goals derived from high level goals.
2 TASK: Traffic Generation and Measurement
(Definition and Software)
Task Leader: R.Hughes-Jones
Task description:
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 Deliverables:
1. [Document] The agreed definition of the simulated-user and background
traffic and the specification of the means of its production, i.e. scripts, tools,
software and hardware.
2. [Document] The agreed definition of required measurement systems and the
specification of the means of making the above measurements, i.e. tools,
scripts hardware etc.
3. [Document] Specification of the success metrics for demonstration that project
technical goals have been achieved.
4. [Software, repository, rpms] Production of all required software
2.1 Sub-Task: Load Traffic
Sub-task Leader : ????
This task encompasses all aspects of test traffic definition and means of generation,
(except for obtaining and deploying associated hardware).
2.1.1 Define simulated-user and background Traffic
This traffic will be used to provide the load against which the test and measurement
probes defined below will characterise the network behaviour.
This sub-task is expected to define traffic patterns and classes such as:
1.
2.
3.
4.
Regular traffic - constant size packet, regular spaced in time
Poisson traffic - constant size, exponential spacing to form transient queues
IETF traffic - different sizes and different probability of each size sent
Play back of real traffic patterns generated from packet headers pre-recorded
from suitable points of the production network. This might include:
 Video Conference traffic -> play back - rude/crude tools
 General traffic captured at edge of a site, e.g. Manchester
5. Web-bursty traffic
6. .....etc....
2.1.2 Specification of software and hardware needed for 2.1.1.
This sub-task is expected to determine and specify the techniques, tools, hardware and
software required to produce the traffic defined by the previous task.
For example the output of this task may include:
1. Selection of existing software to use such as IPERF, UPDMon, mutli-stream
TCP generators.
2. Specification of software to be written by us such as rude/crude tools for
playback of recorded traffic patterns, web traffic simulators.
3. Specification of a control framework to manage traffic generation
4. Specification of the use of PC based equipment
5. Specification of the use of specialist equipment such as Spirent/Agilent
2.1.3 Procure/Produce software defined in 2.1.2
This task encompasses all of the work needed to make the software defined above
available for use within the project. It will include
1. procuring existing software,
2. writing special software/scripts where appropriate
3. creating a “kit of tools” for deployment at the sites (e.g. rpms)
4. it may include production of a framework for automating traffic generation
between sites.
5. it may include setting up of a central repository (eg cvs).
2.2 Sub-TASK: Measurement Systems
Sub-task Leader: ???
This task encompasses the definition of test probes to characterise the behaviour of
the network under a particular network load and particular network configuration.
Definition of the MIBs and suitable access methodology.
2.2.1 Define low level Probe and Characterisation Measurements
This work will describe the experiments and measurements that will be made to
understand the behaviour of the network under various operation conditions. These
measurements will be made on an unloaded network to define the base level
performance, these measurements will also be made under various network load and
particular network configurations.
This sub-task is expected to define tests and measurements such as:



UDP latency v packet size
UDP throughput v packet size, v delay
Jitter - back-to-back, 100us, VC spacing traffic profiles










Packet loss v burst size
Offered rate v achieved rate
TCP latency and throughput v streams, v data size
Increasing RTT with MPLS/LSP
Long test traffic transfers, TCP and GridFTP, non-TCP transport
Test traffic route through network - different paths for different flows
One-way delay?
Detection of any packet size dependencies
Detection of packet re-ordering
Detection of dependency on number of IP flows
2.2.2 Define high level e2e measures which will define
achievement of the goals of the project
This is a key task. The previous subtask concentrstes only on low level measurements
which will allow us to understand the behaviour of the network.
In contrast this task concentrates on defineing the overal e2e demonstrations we wish
to make, and the measurements which will that these have suceeded. This is to include
 Demonstration of functioning e2e IP premium
 Demonstration of functioning e2e QBSS
 Demonstration of correct interoperation of different classes
2.2.3 Specify tools/services to make measurements
Having defined the required tests, this task is to specify the software tools and
hardware required to make those measurements. Also included here is definition of
the access and methods required to record the statistics needed from the routers and
end systems.
This sub-task is expected to define the use of tools and services such as:





SNMP access to MIBs for bytes/packets/errors
Use of Web100 tools -> TCP MIB for each connection
Use of TCP Dump, TCP Trace, PingER, Iperf,
Frameworks such as RTPL? (collaboration?)
Hardware needed such as PCs, switches+splitters, specialist equipment such as
Spirent and Agilent kit.
2.2.4 Procure/produce software for measurements
This task encompasses all of the work needed to make the software defined above
available for use within the project. It will include


procuring existing software,
writing special software/scripts where appropriate



creating a “kit of tools” for deployment at the sites (e.g. rpms)
it may include production of a framework for automating measurements and
collection of results
it may include setting up of a central repository (eg cvs).
3 TASK: Traffic Generation and Measurement:
Equipment provision
Task Leader : I.Bridge ???
Task summary:
This task is (perhaps artificially) separated from the previous task as it may involve
benchmarking, hardware selection, negotiation of collaboration agreements and
purchasing procedures.
3.1 Select/obtain/deploy PC based equipment
Sub-task Leader :????
This task is to address the pratical aspects of the “conventional” equipment specified
by the previous task. It includes benchmarking and selection of suitable PCs, selection
of suitable Ethernet switch equipment, gigabit interfaces, and eventual procurement
planning.
3.2 Select/obtain/deploy Specialist Equipment
Sub-task Leader : Ian Bridge
This is the same as task 3.1 but concerns specialist equipment such as Spirent and
Agilent products. It is expected that this will define the basis of our potential
collaboration with such companies which will include field testing of products and
agreements for loan.
4 TASK: Security
Task Leader :Tim Chown
Task Summary:
All security implications are considered within this task.
<Tim Chown to provide task description>
Task Deliverables:
1. Security guidelines covering all aspects of MB-NG test network and its
configuration.
5 TASK: Traffic Class Definitions / Policies / Policing
PELC : I was unable to write this task based upon the original words in the text version as I dont
have enough relevant experience. Specifically I couldn’t see all the components, the right order, nor
the decomposition into suitable sized and bounded sub tasks (if any). Ive taken words from the
original text document, but probably twisted them so as to be wrong (sorry robin).
Saleems first job is to re do this properly.
Task Leader : S.Bhatti
Collaborators: J.Crowcroft
Task Summary:
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.
Task Deliverables:
1. Traffic class definitions and classification mappings.
2. A defined and agreed set of policies on which the MB-NG test network will
be configured
Should include (taken from original text document):
.
 Definition of aggregate traffic classes we are going to use which will
include IP Premium, BE, QBSS, and will also consider whether AF PHB
bases classes are required.
 Classification of simulated user and background traffic and mapping into
aggregate traffic classes at the edges

For each AD (administrative domain = core, MAN)


 Associate traffic classes with DSCP s
 Define DSCP to queue mappings
 Establish drop policies
 In core establish DSCP to label mapping?????
Define inter-domain mapping policies eg:
 pure IP
 MPLS
 MPLS dropping to IP at domain boundary and gets remapped to
MPLS
Policing ?????
6 TASK: Lab based network equipment configuration
Task leader: ???
Task description:
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.
Deliverable/Success metric: [ Powerpoint presentation] Presentation demonstrating
correct operation of classification and PHB, plus baseline throughput measurements.
Note: this will likely be used for interim project reports hence is asked for as a .ppt
7 TASK: e2e Network equipment configuration
Task leader(s) : Robin Tasker (agrred with Robin) +
Suggest one designated person per AD
- Core: ??
- UCL: ??
- Manchester: ??
- RAL: C.Seelig
A convenor to be chosen from the above. This proposal can be discussed and
varied by the people concerned.
Task description:
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
Task Deliverables: [Document and Powerpoint presentation] A document and
presentation should be produced which specifies the final details of the e2e network
configuration, and includes plots which demonstrate each aspect functioning at the
“connectivity” level (i.e. not necessarily under stress). The accompanying
presentation will be used for interim reports.
7.1 Sub-TASK: Basics
Sub-task Leader : ????
Basics of setting up a full IP network from end user to end user (i.e. across all
participating domains) .Work includes:





Allocation of IP numbers; need different IP networks for AD(C) and AD(M)’s; do
we want to delve into different AS’s? [Note: UKERNA were to make a request for
a Class C - has this been done? given we decided to use global IPs for routing
to/from Internet2/CERN? We can devise an addressing plan independently.]
Configure routers in AD(C) and at AD(M)’s for IP routing
Configure according to agreed security policy defined in task 4
Demonstrate e-2-e IP connectivity .
Observe effect of link failure - packet loss and time to stability
Deliverable/Success metric: [Demonstration] User applications inter-working
between sites, including FTP data replication (GridFTP if possible) and some form of
video conferencing.
7.2 Sub-TASK: Configure IP Diffserv/QBSS enabled in
AD(Core)
Sub-task Leader : ?????
Configure “core” admin domain only for Diffserv/QBSS at IP level, i.e.




Configure edge routers (interfaces?) for packet marking using definitions from
previous tasks.
Configure routers for defined DSCPs to queue mapping and to act on defined
“drop policy”
Demonstrate basic IP connectivity using traffic injected from generators close to
edges
Demonstrate and record test traffic behaviour to demonstrate expected QoS
behaviour.
Deliverable/Success metric: [Demonstration] Informal demonstration to a technical
meeting.
7.3 Sub-TASK: Configure IP DiffServ/QBSS in AD(MAN)’s
Sub task leader: ?????
Configure “MAN” admin domains for Diffserv/QBSS at IP level, i.e.




Configure edge routers (interfaces?) for packet marking using definitions from
previous tasks.
Configure routers for defined DSCPs to queue mapping and to act on defined
“drop policy”
Demonstrate basic IP connectivity within AD(MAN) using traffic injected from
generators close to edges
Demonstrate and record test traffic behaviour to demonstrate expected QoS
behaviour within AD(MAN)
Deliverable/Success metric: [Demonstration] Informal demonstration to a technical
meeting.
7.4 Sub-TASK: Configure e2e IP Diffserv/QBSS across
MAN-Core-MAN
Sub task leader: ?????
Based upon the work of the previous tasks to configure IP based Diffserv/QBSS in
each AD, we now connect it together and demonstrate e2e services.




Peer domains
Demonstrate basis IP connectivity in each traffic class
Inject test traffic from edges and measure behaviour.
...to be expanded..
This task needs significant expansion as it in effect marks one of the key goals of the
project – demonstration of e2e QoS.
Deliverable/Success metric: ?????
7.5 Sub-TASK: Configure MPLS in AD (Core)
Sub-task Leader : ????
Configure the “core” domain for MPLS, firstly just the basics of making and
demonstrating that MPLS works, and secondly using packets marked according to the
defined policy as the input into the MPLS enabled network. In both cases using the
test traffic to characterise the network.
Deliverable/Success metric: ?????
7.5.1 MPLS Basics in AD(Core)
Start in the “core” domain with nothing fancy




Map basic IP routing into LSPs, i.e. set up full-mesh MPLS connectivity
Demonstrate e-2-e IP connectivity
Demonstrate and record e-2-e test traffic
Observe efffect of LSP failover and packet loss / stability
7.5.2 MPLS mapping Traffic Classes in AD(Core)
In the “core” domain but mapping marked IP packets into LSPs





Config edge routers (interfaces?) for packet marking
Use ,MPLS label definitions to configure LSPs between sites
Demonstrate basic IP connectivity
Demonstrate and record test traffic
Observe effect of LSP failover - pkt loss and stability
7.6 Sub-TASK: Configure MPLS in AD(MAN)’s
This is the final step (if time permits) to configure MPLS in AD(MAN) domains for
Diffserv/QBSS and repeat the demonstrations.
8 TASK: Experimental measurements.
Task leader: ???
This task is intended to undertake a systematic and complete set of demonstrations
which allow us to achieve the first goals of the project.
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.
Deliverable: This task represents the first major output of the QoS part of the project.
The deliverables are therefore:
1. A full project report detailing the equipment configuration, the measurements
carried out and the results
2. An accompanying Powerpoint presentation to be used in high profile venues
(eg UK wide eScience meetings, GGF Research Group, Terena meetings.....
8.1 Sub-TASK: Using simulated traffic
All of the above, using the simulated traffic generators.
8.2 Sub-Task: Using real Grid traffic.
All of the above, but using real grid traffic. This will therefore in addition require
planning and execution of work to connect real Grid sources to the test network.
This will be a significant task which will need much more detail working out at about
the project 1 year mark ?
9 Define and demonstrate “Managed Bandwidth
Service”
Task leader: J.Sharp
Collaborators: J.Crowcroft
The preceding work (up to task 8) will have led us to successful demonstration of e2e
QoS across multiple UK domains.
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).
Deliverables:
1. Definition of “replacement MBS” service
2. Demonstration of functioning service
10 Plan and execute extension of demonstrations to
sites in Europe and US
Task leaders: will follow once concrete lines of opportunity are agreed in
principle.
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.
Deliverables/Success metrics: [Demonstration, Report] Successful demonstration of
services operating between end points (success metrics defined in task 1 ) plus
associated documentation thereof.
11 TASK: The Deployment and Integration of
Middleware APIs (GARA)
Task Leader : ???
Collaborators: J.Crowcroft
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.
Task details to be defined
Deliverable/Success metrics: [To be refined]: Demonstration of (indirect?) access to
QoS via application layer APIs.
12 TASK High Throughput programme
Task leader: R. Hughes-Jones
Task description:
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.
Task Deliverables:
1. [Document] A document specifying the work, methodology and tools
required to investigate TCP/IP operation on high bandwidth links. This should
also specify the network configurations and operational policies selected.
2. [Document] A document specifying the work, methodology and tools
required to investigate non TCP/IP protocols on high bandwidth links.
3. [Document] Specification of the data transfer tools to be tested under the
selected network configurations and operational policies. This should also
provide the methods for monitoring and demonstrating that performance has
been achieved.
4. [Demonstrations and Powerpoint presentations] Production of a schedule of
high performance high throughput demonstrations and suitable performance
and publicity information.
12.1 Sub-Task: Investigation of TCP/IP Protocol Performance
Sub-task Leader : Gareth Fairey
This sub-task will define the work required to investigate the operation and
performance of the TCP/IP protocol on high bandwidth links under various QoS
policies. It is expected that the tests will be performed under some of the network
topologies specified in Task 7 by setting the required bits in the TOS IP fields that
correspond to the QoS policy being investigated. It is expected that tests and
measurements will be defined for several different TCP/IP stacks, including the recent
“Fast-TCP” outlined in RFC***, and following Task2, will include:








TCP latency v packet size
TCP throughput v number of streams, v data size
Variation of RTT with MPLS/LSP and QoS conditions
Number of lost / retransmitted packets
Investigation of packet dynamics (i.e. why you don’t get 1Gbit on a 1Gbit
link)
Detection of any packet size dependencies
Detection of packet re-ordering
Detection of dependency on number of IP flows
12.2 Sub-Task: Investigation of Non TCP/IP Performance
Sub-task Leader : ????
This sub-task will define the work required to investigate the operation and
performance of non-TCP/IP protocols on high bandwidth links under various QoS
policies. As well as specifying the set of tests from those defined in Task2, the nonTCP protocols need to be chosen from those in the current literature, and are expected
to include:
 Blast UDP
 Tsunami
 Radio-Astronomy data streaming
 …
The measurements are expected to include:
 UDP latency v packet size
 UDP throughput v packet size, v delay
 Jitter - back-to-back, 100us, VC spacing traffic profiles
 Packet loss v burst size
 Offered rate v achieved rate
12.3 Sub-Task: Selection of transfer Tools and Scheduling of
High Performance e2e testes and demonstrations.
Sub-task Leader : Stephen Dallinson
The task builds on our measurements and understanding of the operation of the
network transport behaviour. It will be one of the more visible outputs of the MB-NG
project both in terms of user requirements, expectations and demonstrations. As well
as defining the tools to be used, it will concentrate on specifying and scheduling the
overall e2e demonstrations we wish to make, together with the measurements which
will show that these have succeeded. The demonstrations will include:
 Demonstration of functioning e2e IP premium
 Demonstration of functioning e2e QBSS
 Demonstration of correct interoperation of different classes
 Demonstration of the transfer of real user data at 0.1, 0.5 1.0 Gbit speeds
for substantial periods of time.
The MB-NG testbed provides the opportunity to demonstrate high bandwidth, high
throughput transfers operating for long periods of time. Together with monitoring
application performance, these tests would investigate the impact on the core network
components, as well as the effect of similar QoS cross-traffic on the transfers
themselves. This will provide evidence to potential uses that such transfers are
feasible today. It is envisaged that these tests would initially be tried for say 1 hour,
then 3, 10, and finally 24+ hours. The aim would be to demonstrate transfer rates
approaching 1 Gbit/s. It is expected that the following transfer mechanisms would be
selected:
o GridFTP
o BBcp
o BBftp
o Radio Astronomy data moving
Note: for real transfers we need to ensure that the disks on our test equipment
are NOT the limiting items. We have ATA100 IDE devices at 7500 rpm with a
data rate of 10Mbytes/s so it is expected that small RAID systems will be needed.
This should be studied.