Transcript Document

Performance Measurement
CANARIE/DANTE/Internet2 Rome Meeting
(Jan 05)
Jeff Boote and Eric Boyd - Internet2
Nicolas Simar - Dante
Agenda






2
Update of Action Items
Internet2/JRA1 Interaction Update
GÉANT2-JRA1 Activities
Internet2 performance activities
High level framework description
Summary: Internet2/JRA1 Next Steps
Action Item Update
 A5 - Light Path (intermediate
measurements)
 A6 - Joint White Paper
 A7 - Joint SW Development Feasibility
 A8 - Regularly Scheduled Tests
3
A5: Light Path Intermediate
Measurements
• Goal: Figure out how to do partial path
analysis of a lightpath.
• Real technical challenge.
• No real progress yet
• Internet2 HOPI project will need to address
this.
• JRA3 will be following this topic.
4
A6: Joint White Paper
• First draft largely complete
• Current development from participants
is focus on JRA1 General Framework
Document
• (JRA1 General Framework Document
acting as the technical description of the
architecture to be included in the Joint
White Paper, the joint white paper being
broader as it will also include use-case)
• Will continue to iterate until JRA1 GFD
deadline (due Mid February)
5
A7: Joint SW Development
• Open Source Development Plan
• http://people.internet2.edu/~eboyd/Joint_Open_Sour
ce_Development_Environment.pdf
• BSD Style License (GN2 to determine the exact GN2
contract requirements and their impacts on the
license)
• Shared authority structure
• Sourceforge (most likely) development environment
• Disengagement non-punitive (a carrot for
participation)
• Both projects have similar structure involving several
partners working on the same issues.
6
A8: Test Links between
GEANT and Abilene
• On-demand is available between Abilene and GÉANT
• http://e2epi.internet2.edu/pipes/pmp/pmp-dir.html
• Preparing for regular measurements
 Los Angeles <-> CERN lightpath
• OWAMP and BWCTL monitoring constantly
http://ndb1-blmt.abilene.ucaid.edu/lightpath/
 piPEs Software Evaluation
• PSNC (Poland) reviewed Internet2 efforts in a whitepaper
• PSNC deploying BWCTL, OWAMP, piPEs Measurement
Framework v0.1 alpha prototype
• Ongoing discussions as part of Architecture discussions
7
Agenda






8
Update of Action Items
Internet2/JRA1 Interaction Update
GÉANT2-JRA1 Activities
Internet2 performance activities
High level framework description
Summary: Internet2/JRA1 Next Steps
Internet2/JRA1 Joint Activities
 UCL E2E Monitoring Workshop 2003
• http://people.internet2.edu/~eboyd/ucl_workshop.html
 Internet2, DANTE, CANARIE biannual meetings (12/03, 07/04,
01/05)
 Transatlantic Performance Monitoring Workshop 2004
• http://people.internet2.edu/~eboyd/transatlantic_workshop.html
 Caltech <-> CERN Demo
• March ’04
• November, December ‘04
 Haystack, USA <-> Onsala, Sweden
• In use by eVLBI community
• Added SUnet node to the available mix through outreach to that group
9
Internet2/JRA1 Joint Activities
 Contribution to the GGF NM-WG
• both Internet2 and Dante provided a significant contribution to the
effort (four to five people contributing regularly - 2 from Europe, 2-3
from US)
• Contribute to design, early adoption and prototyping, feedback
 General Framework Design
• Workshop on the General Framework design in Brussels
• Weekly conf calls, joint mailing list
 Installation of tools : Internet2 OWAMPs, Internet2 BWCTLs,
Internet2 piPEs framework, DFN IPPMs and their evaluation.
 Use-cases.
10
Internet2/JRA1
General Framework Design
Metcalf’s Law
 Our version: The value of a performance
measurement framework scales with the square of
the deployment footprint
 One organization cannot create a successful
measurement framework in a vacuum
 GGF NMWG: Enable multiple measurement
frameworks to work together
• piPEs, MonALISA, Advisor, and AMP
• Demonstrate interoperability of NMWG schema
• Working to build demo with EGEE JRA4 (PMP) for GGF13 in
March involving piPEs, AMP, and Asian PMPs
 Shared goal of building a next generation
11 measurement framework
Agenda






12
Update of Action Items
Internet2/JRA1 Interaction Update
GÉANT2-JRA1 Activities
Internet2 performance activities
High level framework description
Summary: Internet2/JRA1 Next Steps
GÉANT2-JRA1 Activities
 Requirements
• Three questionnaires were written targeting: the NRENs, the
projects and the end-users.
• Goal: get an overview of
- the existing monitoring infrastructure (metric, tools used)
- the visualisation of the data
- the need to access monitoring information from other networks.
• 45 answers were received in total (respectively 16, 14, 15)
 Strong interest to access monitoring information form
multiple network.
13
• NRENs: less than 5-10% of the problems they are encountering
involves several domains ( => times 30 NRENs). They want to
see improved the capability of localising the problems.
• International projects want to have a view on what’s happening
between their sites (uses: troubleshooting, SLA and internal
decision making).
• End-user: less important than for NRENs or projects (uses:
troubleshooting, service verification)
GÉANT2-JRA1 Activities
 Readiness to open access to measurement data
• Some ready to show everything (or nearly so)
• Some want to apply restriction (about what and to who)
• Some don’t want to
 Monitoring Information:
•
•
•
•
•
•
RTT and OWD
bandwidth utilisation and achievable TCP throughput
RTT and OWD packet loss
Delay variation
Interfaces error and drops
Routing/path information
 On-demand capability (to and from other domains)
14
GÉANT2-JRA1 Activities
 Be able to monitor the services deployed
•
•
•
•
•
IPv4/IPv6
Multicast/unicast
IP QoS
VPN/point-to-point connections
Emulate behavior close from the one from the
application used
 Different tools used amongst the networks,
need to abstract the data provided from the
type of measurement tools used.
• Provide data through a well define interface.
• Inter-operability between tools.
15
GÉANT2-JRA1 Activities
 Keep in mind: installation and maintenance!
 Had a look at existing tools and went more in depth
for the most interesting ones.
 We have chosen so far the following tools:
•
•
•
•
•
OWD: DFN IPPM
Throughput: iperf based
Flow monitoring: flowtool
Visualisation: CNM
Pending: Packet capture tool (SW: scampi - tbc, HW:
Endace or scampi - further work needed), other visualisation
16
GÉANT2-JRA1 Activities
 Current actions
•
•
•
•
General Framework Design v1 (mid-February)
Prototype (June-July 05)
Work on measurement concatenation (now -> September)
Buy equipment and install it.
 Next steps
• AA (discussion with JRA5)
- Which model to follow?
- Authorisation based on groups (NOC, PERT, projectA, user).
How to have easy agreement between domains? (don’t want to
negotiate an agreement with all the US universities or with all
the European NRENs)
• Detailed design of the modules v1 (September 05)
• Trial phase (November 05-December05)
17
Agenda






18
Update of Action Items
Internet2/JRA1 Interaction Update
GÉANT2-JRA1 Activities
Internet2 performance activities
High level framework description
Summary: Internet2/JRA1 Next Steps
piPEs
 BWCTL
• Stable - fair amount of interest
 OWAMP
• Significant changes to specification.
IETF working group last call
completed
• New version of implementation
forthcoming to reflect the changes
19
piPEs
 NDT
• Redirection to closest NDT server within a
group of servers
• Funded to significantly improve
understanding and detection of duplex
mismatch problems (NIH/NLM Grant)
 PMP registry
http://e2epi.internet2.edu/pipes/pmp/pmpdir.html
20
Bridging the Gap Workshop
(NSF)
 Explore network performance solutions
across scientific application communities
•
•
•
•
21
Network experts
Researchers (network users)
Network application developers
Campus network engineers
Internet2 Detective
 Evaluating future development using
SURFnet Detective platform
 Strategic investment: Gateway for naïve
entrance to advanced services like
Shibboleth and Pipes
22
Internet2 Transport Effort
 Congestion control researchers/high-end
users (led by Stanislav Shalunov)
 Goal: user-space transport tool
• High performance: Suitable for both bulk file
transfer and interactive multimedia
• Tolerance for minor non-congestive packet loss
• Completely end-to-end: no router modifications
• Portable, easy to install and use (no kernel
modifications)
• Advanced congestion control using existing
research
 https://mail.internet2.edu/wws/arc/transport
23
Agenda






24
Update of Action Items
Internet2/JRA1 Interaction Update
GÉANT2-JRA1 Activities
Internet2 performance activities
High level framework description
Summary: Internet2/JRA1 Next Steps
General Framework Overview




25
Architecture refinement
Proposal
High-level description of components
Interaction description
Architecture Refinement
 Review of existing systems
• Insights based upon Abilene prototype framework,
DANTE’s perfmonit and IPPM experiences
 New insights gained from inter-domain
framework test experience (lightpath
measurements, Abilene/ESnet, etc)
 Additional use cases and experience of
collaborators
• Internet2, GÉANT2 JRA1, GGF NMWG
26
Architecture Proposal
 Services Oriented Architecture
• In a simple scenario, each domain consists
of a set of services. All services are well
defined and independent
• Services within a domain represent the
domain with the help of Authentication and
Authorization – they respond to requests
only if the Authentication service of the
domain has authenticated the user and the
policy of the given service authorizes it
27
Basic Services






Lookup
Authentication
Measurement Point
Measurement Archive
Resource Protector (Authorization)
Aggregation
• Topology
28
Measurement Point
 Service to wrap measurement tools
 Interacts with resource protectors to protect
shared resources
 Registers with lookup service and specifies
the authentication credentials required to
interact
 Registers with lookup service to indicate
types of tests it can perform
 Accepts requests for tests
29
Test Request (Initialization)
Initialization Phase: Registration/Lookup
5) Presen
t
credentials
, rece
Test Request Client
4)
Fin
d
Te
st
Authentication
ter
egis
1) R
Pe
ers
 Lookup will be P2P
 “Bootstrapping” can use some combination of:

Well known hosts

Broadcast

Multicast
r
giste

Previously detected
1) Re
Test Executor
ive authto
ken for Te
st Executo
rs
Lookup
1) R
egis
te
r
Test Executor
30
Lookup Service
 Initial discovery
• Multicast / Anycast
• Well known servers
• Required servers (by administrative
configuration)
• Previously detected servers (organized in a
P2P network – lookup services find out
about other lookup services…
31
Lookup Service (II)
 Lookup is not simply by name
•
•
•
•
•
•
Type (type of measurement, type of service)
Community
Network path (proximity information from Topology)
Organization
Type of authentication required
Other…
 Response contains
•
•
•
•
32
Contact information
Available services
Authentication required
Other…
Authentication
Registers with lookup
Client requests “kind” of authentication token
based lookup results
Authentication grants time-limited token used
to request service
Protocol for determining “role/identity” for
request. (Shib: federated trust)
• Allow new measurement points to be created as
easily as possible
• Allow new data consumers access as easily as
possible
33
Process Flow (Client)
 Discovery.
• Find lookup servers.
• Use lookup servers to find tool beacons for a given problem.
(On correct path, with acceptable authentication
requirements, with acceptable tools/measurements.).
 Authentication.
• Authenticate to correct auth servers that are needed for
desired test executors.
 Test execution.
• Implement subscriber to accept results.
• Make test requests presenting credentials and reference to
subscriber interface for returned data.
34
Full Test
Test Request
eqs)
t Resu
lts
ule re
q
ureme
n
4) Mea
s
(para
m/sch
ed
quest
3) Te
)
st Re
q
re
e
ul
ed
s
ch
/s sult
m
e
ra
tR
pa
en
t(
es r e m
qu
u
Re eas
st
M
Te
5)
Test Executor
35
r
ing auth
3)
Authentication
(includ
t Peers
s
e
T
d
1) Fin
)
2) P
r
rec esent
eive
cre
Tes autht dentia
ls
t Ex oke
ecu n fo ,
r
tors
Test Request
Client
4) Measurement
Test Executor
Lookup
Request Phase (Scheduling)
Request Phase
Test Request
Test Executor
“A”
36
m/
a
r
Client
3) T
(pa
t
est
s
)
Re
ue req
q
q
e
”
e
A
t
l
” av uest
x
t R edu
e
s
(pa
4) T
ail
/n
ram
T e s ch
t
w
i
m
e
)
t
s
1
e
/
p
t
)
Ac c
ce e
c
e
m
A
i
pt w
st a i l t
/ne
t
e
i
m
v
T a
xt a
e
)
2
v ai
l
 Client repeats steps 1-4 until the time
returned from “A” matches the time
returned from “B”.
 Each TestExecutor will have a
maximum time into the future it is
willing to schedule a test - after that
time it will return “denied”
 The client will have a maximum time
into the future it is willing to schedule
a test - after that time it will not
accept a slot offered by a
TestExecutor.
Test Executor
“B”
Resource Protector
 Enables centralizing of resource allocation
(not globally - this is within spheres of
administrative control)
 Multiple measurement points interact with a
given resource protector to limit the shared
resources
 Resource protectors can be chained
hierarchically to control aggregations of
shared resources across larger frameworks.
37
Resources Protectors
Brokering - In depth (Scheduling shared resources)
Resource Broker

TestExecutor can deny under its own
authority
 TestExecutor can be configured to
check with 0 or more Resource
Brokers for a secondary check
 The ResourceBroker is what allows
individual resources to be shared
among multiple TestExecutors
 The ResourceBroker can deny a
request under its own authority
 The ResourceBroker can be
configured to check with 0 or more
additional ResourceBrokers to allow
resource aggregation. (Recursion is
not allowed)
Test Request
Client
38
Link
Resources?
Yes - retun
accept
No - return
deny
Resource Broker
Host
Resources?
Yes - request
Link
return result
No - return
deny
Test Executor
1) Te
(param st Request
eters/s
chedu
le)
Parameters
Valid?
Yes - request
Host
return result
No - return
deny
Measurement Archive
 Subscribes to some set of data – either
from a measurement point or from an
aggregation service
 May publish the derived data sets
39
Topology
Network topology information is necessary for
measurement system optimization
Creates overviews/”maps” to illustrate network
Layered approach (domain level through to
wavelengths and physical level)
Specific type of aggregation (translation)
• Collects raw data from measurement points and
pushes topology information into the lookup service
(allows topologically based queries to lookup
service)
40
Topology (Initialization)
Lookup
Archive
Current Topology
MP1
Tests
Historical/Full
Topology
Topology
41
MP2
Aggregation (Translation)
 Data translation service (pipelines data
between other components in the framework)
 Subscribes and Publishes data
 Provides:
•
•
•
•
•
Aggregation
Correlation
Caching
Duplication
Translation
- Event generation
- Data analysis
42
Agenda






43
Update of Action Items
Internet2/JRA1 Interaction Update
GÉANT2-JRA1 Activities
Internet2 performance activities
High level framework description
Summary: Internet2/JRA1 Next Steps
Summary: Internet2/JRA1
Collaboration Next Steps
 Open Source Shared Development
• Sourceforge-based Sub-Projects
• Modified Berkeley Licensing





44
Common Service-based Architecture
Architecture spans superset of deployment use cases
~Quarterly face-to-face meetings
~Weekly phone conferences
Split development according to interest, resources
General Framework Next
Steps
 Architecture continuing to be refined
 Architecture validation
• Detailed use-case flow descriptions
• Interfaces
• Prototypes
 New Action Item: Jointly developed,
services-based, measurement
framework prototype by Summer ‘05
45
Internet2/JRA1 Interaction
Update
 Agreement from the management on the way
to proceed for the joint development, license,
and open-source
 Clarification from GN2 on the impact of the
GN2 contract on the license
 Agreement on AA as it covers several groups
(Possibly should be deferred until AA
discussion)
 Openness to share measured information
 Will have to set-up measurement peering
agreements (who can do what, and up to
what extent)
46
Questions?
47