piPEs Server Discovery – Adding NDT testing to the piPEs architecture Rich Carlson Internet2 April 20, 2004

2 Design Goals  Allow users to run short test from desktop/laptop computer  Provide a single entry point into measurement domain  Multiple servers act in concert, automating the server selection process

April 20, Basic Assumptions  A collection of testing servers are placed at the network’s edge  Test requests come from ‘outside’ the network  Users can test to the ingress or egress point of the network  User doesn’t know which server is at ingress or egress

April 20, Server Locations

April 20, Ingress point Benefits  Closer to client (user’s desktop)  Shorter network path, fewer links to analyze  Reduces test traffic over network core  Better for finding configuration problems with client host/network

April 20, Egress point Benefits  Closer to destination  Approximates the path an application will use  Better for finding E2E performance problems

April 20, piPEs Design Choice  All information for ingress testing is supplied in the initial connection request Packet goes to testing engine, indicating intent Packet contains client IP address  Destination information needs to be supplied for egress testing  Testing service will support both, but will prefer ingress point testing

April 20, piPEs Design Choice  Leverage existing NDT code to speed up development  Add in additional features to integrate First/Last Mile (FLM) servers into piPEs test environment

April 20, Server Discovery  User contacts any server in the piPEs federation  Server runs discovery process to find ingress server  Client re-directed to ingress server

April 20, piPEs Approach – Build Traceroute tree map  Collection of servers S1 to S8 form measurement domain  All servers obtain traceroute data for all peer servers in the domain  Routes are stored in a tree based map  Note: all servers perform this off-line task

April 20, Sample Traceroute Tree map R6 R7 R5 R4 R3 R2R1 S2S3 S7S8 S1 S6 S5S4

April 20, piPEs Approach – When client requests a test  Client connects to server S1 requesting a test  Server S1 runs traceroute back to client IP  Server S1 compares client route to core map  Note: All servers will perform this task

April 20, Sample Traceroute from S1 to Client R5 R4 R1 S1 Rc Rb Ra Client Traceroute to Client

April 20, Sample Comparison between map and path from S1 to client  Traceroute Map S1 R1 R4 R5 S6  Traceroute to client S1 R1 R4 R5 Ra Rb Rc Client

April 20, piPEs Approach – Picking the Ingress server  Comparison showed that server S6 is the ingress server, redirect client to S6 Prefer configuration testing  Server S1 creates a dynamic html document that re-directs the client to server S6

April 20, Client re-directed to S6 for test Rc Rb Ra Client R5 S6

April 20, piPEs Approach – Picking the Another server  Allow client to find egress server Allow performance testing Client provides destination name/address Ingress server will use traceroute map to find egress server and re-direct client  Allow client to manually select any server in the cloud

April 20, Prototype implementations  Modified NDT web server to: Perform server discovery process Dynamically generates re-direct page  Modified NDT testing engine to interoperate with other piPEs testing functions (BWCTL, OWAMP) Schedules multiple requests in FIFO manner Will interact with meta-scheduler

April 20, Next Steps  Start deployment of NDT servers in Abilene core Requires Web100 enhanced Linux server Generic name “ndt-city” – Do we want/need a single central name?

April 20, Additional info  StarLight server now operational No access from commodity Internet  Command Line version of client code under development (web100clt) Compiles and runs under Linux and FreeBSD