Docstoc

Internet End to End Performance Initiative

Document Sample
Internet End to End Performance Initiative Powered By Docstoc
					piPEfitters
Salt Lake City Jt Techs (Feb 05)

 Jeff Boote - Internet2
       Agenda

Current activities and Tools update
High level framework description
Summary: Next Steps




                                       2
      piPEs
BWCTL
 • Stable - fair amount of interest
 • Recent requests for additional functionality
   (parallel streams, multicast)
OWAMP
 • Significant changes to specification. IETF
   working group last call completed
 • New version of implementation forthcoming
   to reflect the changes (BEFORE SMM!)

                                                  3
        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/pmp-dir.html



                                                      4
         piPEs

•Internet2 Detective
  • Strategic investment: Gateway for naïve entrance to
    advanced services like Shibboleth and Pipes
  • Evaluating future development using SURFnet Detective
    platform




                                                            5
           Current work: Joint Development
           with Geant2 (JRA-1)
Rather than build two separate interoperable
 measurement frameworks, why not jointly
 develop a single measurement framework?
Steps:
  •   Agree to joint open source development √
  •   General Framework Design √
  •   Prototype (Summer ’05)
  •   Detailed Design
  •   Implementation
Seek participation from NRENs & campuses,
 particularly Internet2 & ESnet members
  • Thrice weekly conference calls
  • Very active mailing list
  • 2-3 face-to-face meetings per year
                                                 6
       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


                                                       7
          Design Goals
 Dynamic, self-organizing characteristics identical to
  that of the network as a whole
 Recognize and facilitate the ability of independent
  network entities to set policies and limits on the use of
  measurement resources locally
 Encourage and facilitate the use of measurement
  resources by users interested in network paths that
  traverse remote administrative domains
 Facilitate the widespread adoption of new
  performance tools in a broad, E2E framework
 Allow framework to evolve over time


                                                          8
        Architecture Proposal
Services-Based Measurement
 Framework for Building Dynamic, Self-
 Organizing Performance Communities
  • 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


                                                          9
       Basic Services

Lookup
Authentication
Measurement Point
Resource Protector (Authorization)
Measurement Archive
Aggregation
  • Topology


                                      10
                   Test Request (Initialization)
                                    Initialization Phase: Registration/Lookup



                                 5) Presen
                                           t   credentials                                                           Authentication
                                                           , rece        ive authto
                                                                                   ken for Te
      Test Request Client                                                                    st Executo
                                                                                                       rs
                                         4)
                                              Fin
                                                  d   Te                                             ister
                                                         st   Pe                              1) Reg
                                                                   ers

 Lookup will be P2P
 “Bootstrapping” can use some combination of:
                                                                                   Lookup
    Well known hosts
    Broadcast
    Multicast
                                                           r
    Previously detected                             giste
                                              1 ) Re
                                                                                              1) R
                                                                                                     egis
                                                                                                            te r
                              Test Executor


                                                                                                            Test Executor




                                                                                                                                      11
        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…




                                                         12
           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
  •   Contact information
  •   Available services
  •   Authentication required
  •   Other…


                                                           13
          Authentication Service
 Registers with lookup
 Client requests “kind” of authentication token based
  on lookup results
 Authentication grants time-limited token used to
  request service
 Attribute service created to protect privacy and
  support role-based authorization
   • Allow new measurement points to be created as easily as possible
   • Allow new data consumers access as easily as possible




                                                                        14
Authenticated Service Request
(see notes for slide)




                                15
Federated Identity Service Request
(see notes for slide)




                                     16
        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


                                               17
         Client Process Flow
Discovery.
  • Find lookup servers.
  • Use lookup servers to find measurement tool (MPs) 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 MPs.
Test execution.
  • Implement subscriber to accept results.
  • Make test requests presenting credentials and reference to
    subscriber interface for returned data.

                                                                 18
       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 to control
 aggregations of shared resources




                                             19
Flow for Measurement Request




                          20
                 Resources Protectors
                      Brokering - In depth (Scheduling shared resources)

                                                                Resource Broker
 TestExecutor can deny under its own
  authority                                                                 Yes - retun
                                                                              accept
 TestExecutor can be configured to                             Link
  check with 0 or more Resource                              Resources?
                                                                            No - return
  Brokers for a secondary check                                               deny
 The ResourceBroker is what allows
  individual resources to be shared
  among multiple TestExecutors
 The ResourceBroker can deny a
  request under its own authority                              Resource Broker
 The ResourceBroker can be                                               Yes - request
  configured to check with 0 or more                                          Link
                                                                Host      return result
  additional ResourceBrokers to allow
                                                             Resources?
  resource aggregation. (Recursion is                                      No - return
  not allowed)                                                               deny




                                                                 Test Executor
             Test Request                                                 Yes - request
                Client                 1) Te
                                                                              Host
                                   (param st Request         Parameters   return result
                                           eters/s             Valid?
                                                  chedu                    No - return
                                                       le)
                                                                             deny




                                                                                          21
       Measurement Archive

Subscribes to some set of data – either
 from a measurement point or from an
 aggregation service
May publish the derived data sets




                                           22
           Transformation Service
Pipelines data between other components in
 the framework
Subscribes and Publishes data
Provides:
  •   Aggregation
  •   Correlation
  •   Caching
  •   Duplication
  •   Filtering
  •   Translation
        – Event generation
        – Data analysis


                                              23
        Topology
Specific type of transformation service
 (correlation)
Network topology information is necessary for
 measurement system optimization
Creates overviews/”maps” to illustrate
 network
Collects raw data from measurement points
 and pushes topology information into
 Measurement Archives
Lookup service makes queries to MAs to
 deduce topological adjacencies. (allows
 location based queries to lookup service)       24
        General Framework Next Steps
Architecture continuing to be refined
Architecture validation
  • Detailed use-case flow descriptions
  • Interfaces
  • Prototypes
Jointly developed, services-based,
 measurement framework prototype by
 Summer ‘05


                                          25
        Summary: Next Steps
Open Source Shared Development
  • Sourceforge-based Sub-Projects
  • Modified Berkeley Licensing
Common Service-based Architecture
Architecture spans superset of deployment
 use cases
~Quarterly face-to-face meetings
~Thrice-Weekly phone conferences
Split development according to interest,
 resources

                                             26
          Questions?
Are you interested in participating?
   • Contact eboyd@internet2.edu
Talks of Interest
   • Measurement SIG
       – Tuesday, 7 PM, Marriot Ballroom 1
   • Transport Track session for a introduction into efforts of ad
     hoc working group aiming to get benefit of kernel level
     congestion control algorithm improvements into a user level
     bulk FTP tool
       – Wednesday, 10:25 AM, Saltair
   • GGF NMWG meeting for a detailed discussion of a common
     measurement schema
       – Wednesday, 2:00 PM, Willow Room, 4th Floor




                                                                     27

				
DOCUMENT INFO
Categories:
Tags:
Stats:
views:0
posted:6/20/2012
language:
pages:27