20020405-TE-QoS-schedule.txt Scheme of Tests and Demos Milestones and Schedules Robin Tasker 5 April, 2002 # # This document defines the set of tasks required by MB-NG. Specifically it # defines the traffic that will be run across the network including the # background and simulated user traffic, and the test traffic used to probe the # behaviour of the network under the described conditions. # # This document develops the experimental schedule of MB-NG to include the use # of diffserv (EF, AF, QBSS) and MPLS within the test network environment. Its # intent is to describe the entire problem space from which a realistic set of # experiments can be designed to meet the deliverables of the project. # # Includes input from Richard Hughes-Jones; Ian Bridge; Tim Chown and Jon # Crowcroft. # Points to security work from Tim Chown 1 TASK: Traffic Definitions/Production and Measurement Task Leader <...> # Task Summary # # This task is divided into three sub-tasks, the first two deal with the # definition and means of production of traffic for the MB-NG tests, and # the third sub-task with the means of monitoring and measuring across the # test network. # # Task Deliverables # # 1. The agreed definition for the background simulated user traffic # 2. The means of its production, i.e. scripts # 3. The agreed definition for the test traffic # 4. The means of its production, i.e. tools, scripts etc # 5. Monitoring capability for the above, i.e. scripts, tools etc 1. Sub-TASK: Define background traffic / simulated user traffic, Sub-task Leader <...> # Sub-task Summary # # This traffic will be used in two ways; firstly to provide a true # background load against which the test probes defined below will # characterise the network; and secondly to demonstrate the gross effects # of the particular network configurations described below # 1. Regular traffic - constant size pkt, regular spaced in time 2. Poisson traffic - constant size, expedential spacing -> transient queues 3. IETF traffic - different sizes and different probability of each size sent 4. Run, for example, AG VC and record traffic -> play back - rude/crude tools -> known repeatable traffic load/distribution or capture traffic headers at edge of a site, e.g. Manchester, and use it to reproduce a traffic stream 5. Web-bursty traffic 6. Ability to scale load as % of provision 7. Use of 3rd party traffic 2. Produce scripts to generate traffic defined in 1.1 3. Sub-TASK: Define test traffic Sub-task Leader <...> # Sub-task Summary # # Definition of test probes to characterise the behaviour of the network # under particular network load and particular network configuration. The # specific tools to be used are described in 1.5 below. # 1. UDP latency v packet size 2. UDP throughput v packet size, v delay 3. Jitter - back-to-back, 100us, VC spacing traffic profiles 4. Packet loss v burst size 5. Offered rate v achieved rate 6. TCP latency and throughput v streams, v data size 7. Increasing RTT with MPLS/LSP 8. Long test traffic transfers, TCP and GridFTP, non-TCP transport 9. Test traffic route through network - different paths for different flows 10. One-way delay? 11. Detection of any packet size dependencies 12. Detection of packet re-ordering 13. Detection of dependency on number of IP flows 4. Produce scripts to generate test traffic in 1.3 5. Sub-TASK: Monitoring capability of background and test traffic flows Sub-task Leader <...> # Sub-Task Summary # # Definition of tools need to generate test traffic and to measure and # monitor # 1. SNMP access to MIBs for bytes/packets/errors 2. Access to Web100 tools -> TCP MIB for each connection 3. TCP Dump, TCP Trace 4. UDPmon for UDP tests collects its own data 5. RTPL? (collaboration?) 6. Iperf (iperfer? - UCL) 7. Multi-stream TCP measurer from RHJ 8. Smartbits 2 TASK: Basic Policies - Traffic Class Definitions / Policing Task Leader <...> # Task Summary # # Policy is defined here and used in the configuration of the test network. # 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. A defined and agreed set of policies on which the MB-NG test network will # be configured 1. Defined traffic classes - {IP Premium, BE, QBSS} 2. Separately for AD(C) and each of the AD(M)'s, 1. Assign test traffic elements into traffic classes 2. Associate traffic classes with code points, 1. DSCP i.e. EF, AF, QBSS 2. MPLS label etc -> traffic class marking 3. For diffserv/QBSS establish "drop policy" (WRED, ECN etc) 4. Define DSCP to queue mappings 3. Define inter-domain mappings for all (2.2.2) 4. Policies can be one-to-one mapping or re-mapping within 1. pure IP 2. MPLS 3. MPLS dropping to IP at domain boundary and gets remapped to MPLS 3. TASK: Security Task Leader # Task Summary # # All security implications considered here! Relates to the whole project but # referenced from 4.1 Basics (getting started) below. This work has begun # separately and is mentioned here for completeness. # # Task Deliverables # # 1. Security guidelines covering all aspects of MB-NG test network and its # configuration 4. TASK: Lab / Network Configuration Task Leader <...> # # Task Summary # # This task is divided into a number of sub-tasks which reflect the increasing # complexity of the work defined, and each task builds upon the experience and # results of the preceding ones. # # 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 # # 1. The experimental results of the MN-NG Project 0. Sub-TASK: Working in the Lab Sub-task Leader <...> # # Much useful stuff can be done without a test network! # i.e. stand-alone (ie. single box) QoS/queueing performance tests # 1. The OSR/GSR cards are extremely new and potentially 'buggy' ? 2. The roll-out of some of the WAN connections appears to be likely to slip. So, delivery of Cisco equipment may occur before there is a WAN connection available. These tests would provide a useful activity in the interim. 3. It may be easier to create and identify QoS/queueing problems in isolation rather than whilst the equipment is embedded in a WAN. 4. 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. 1. Sub-TASK: Basics (getting started) Sub-task Leader <...> # Sub-task Summary # # First things first on the test network! # # Sub-task Deliverables # # 1. Configuration of the network # 2. Items 3 - 5 below # 1. Allocation of IP numbers; need different IP networks for AD(C) and AD(M)'s; do we want to delve into different AS's? Closely associated with Security -> (3.) -> T Chown [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.] 2. Config routers in AD(C) and at AD(M)'s for IP routing 3. Demonstrate e-2-e IP connectivity / background traffic 4. Demonstrate and record e-2-e test traffic (1.3) 5. (4.1.4) with background traffic (1.1) 6. Effect of link failure - packet loss and time to stability # # This is a task in its own right, defined elsewhere! # 7. Security -> (3.) -> T Chown # 8. OS and Kernel definition and installation 1. 2.4.9 kernel for Web 100 2. RedHat 7.2 2. Sub-TASK: DiffServ/QBSS enabled in AD(C) Sub-task Leader <...> # Sub-task Summary # # "core" admin domain only with diffserv # # Sub-task Deliverables # # 1. Items 3 - 5 below # 1. Config edge routers (interfaces?) for packet marking using definitions for (2.2.2.1) and (2.2.2.2) 2. Config routers for defined DSCPs to queue mapping (2.2.4) and to act on defined "drop policy" (2.2.3) 3. Demonstrate basic e-2-e IP connectivity / background traffic 4. Demonstrate and record e-2-e test traffic (1.3) 5. (4.2.4) with background traffic (1.1) 3. Sub-TASK: DiffServ/QBSS enabled in AD(M)'s Sub-task Leader <...> # Sub-task Summary # # "man - core - man" domains with diffserv # # Sub-task Deliverables # # 1. Items 4 and 5 below # 1. Config edge routers (interfaces?) for packet marking using definitions for (2.2.2.1) and (2.2.2.2) 2. Config routers for defined DSCPs to queue mapping (2.2.4) and to act on defined "drop policy" (2.2.3) 3. Config boundary routers - AD(M)'s and AD(C) - for inter-domain mapping (2.3) 4. Based on AD(M) - AD(C) - AD(M) configuration, 1. Demonstrate basic e-2-e IP connectivity / background traffic 2. Demonstrate and record e-2-e test traffic (1.3) 5. (4.3.4) with background traffic (1.1) 4. Sub-TASK: MPLS enabled in AD(C) Sub-task Leader <...> # Sub-task Summary # # Only the "core" domain configured here; 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. # 1. MPLS Basics in AD(C) # # Start in the "core" domain with nothing fancy # 1. Map basic IP routing into LSPs, i.e. set up full-mesh MPLS connectivity 2. Demonstrate e-2-e IP connectivity / background traffic 3. Demonstrate and record e-2-e test traffic (1.3) 4. (4.4.1.3) with background traffic (1.1) 5. Effect of LSP failover and packet loss / stability 2. MPLS mapping Traffic Classes in AD(C) # # In the "core" domain but mapping marked IP packets into LSPs # 1. Config edge routers (interfaces?) for packet marking using (2.2.2.1) and (2.2.2.2) 2. Use {traffic class,MPLS label} definitions (2.2.2.3) to config AD(C) LSPs between sites 3. Demonstrate basic e-2-e IP connectivity / background traffic 4. Demonstrate and record e-2-e test traffic (1.3) 5. (4.4.2.4) with background traffic (1.1) 6. Effect of LSP failover - pkt loss and stability 5. Sub-TASK: MPLS enabled in AD(M)'s Sub-task Leader <...> # Sub-task Summary # # More complex configuration : "man-core-man" domains, ; 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. # 1. MPLS Basics in AD(M)'s # # Just the basics but through 3 domains # 1. Map basic IP routing into LSPs, i.e. set up full-mesh MPLS connectivity 2. Based on AD(M) - AD(C) - AD(M) configuration, 1. Demonstrate e-2-e IP connectivity / background traffic 2. Demonstrate and record e-2-e test traffic (1.3) 3. (4.4.1.2) with background traffic (1.1) 4. Effect of LSP failover - pkt loss and stability 2. MPLS mapping Traffic Classes in AD(M)'s # # The most complex of all - 3 domains, MPLS everywhere and marked IP # packets being allocated to LSPs throughout # 1. Config edge routers (interfaces?) for packet marking using (2.2.2.1) and (2.2.2.2) 2. Use {traffic class,MPLS label} definitions (2.2.2.3) to config AD(M) LSPs between sites 3. Config boundary routers - AD(M)'s and AD(C) - for inter-domain mapping (2.3) 4. Based on AD(M) - AD(C) - AD(M) configuration, 1. Demonstrate basic e-2-e IP connectivity / background traffic 2. Demonstrate and record e-2-e test traffic (1.3) 5. (4.5.2.4) with background traffic (1.1) 6. Effect of LSP failover - pkt loss and stability 5. TASK: Use of real Grid Traffic Task Leader <...> # Task Summary # # The use of real Grid application traffic across the test network configured # according to the defined policies to demonstrate capability. 6. TASK: The Deployment and Integration of Middleware APIs (GARA) Task Leader <...> # Task Summary # # Goes here! 7. TASK: Managed Bandwidth Service Task Leader <...> # Task Summary # # One of the motivations for the MN-NG Project was to examine the options for # the Provision of a managed bandwidth service across JANET to replace the # equivalent one offered over SJ-III. This task will make use of the MB-NG # experiments and the experience gained to attempt to define who such a service # may be offered on SJ TIMETABLE Time (Months from Start): S 3 6 9 12 15 18 21 24 Task Start: T1............o....(refinements as needed) o=deliverable T2............o......o......o.....o.......o T3............o....(as needed).................... T4.0...o T4.1...o T4.2...o T4.3...o T4.4...o T5.....o T6.....o T7.....o