Changes between Version 43 and Version 44 of Gec7InstMeasWGAgenda

Timestamp:

03/24/10 18:21:50 (14 years ago)

Author:

hmussman@bbn.com

Comment:

--

Gec7InstMeasWGAgenda

@@ -327 +327 @@
 
 Purpose:
-Provide a comprehensive and ordered list of topics that must be addressed for a complete architecture
-Identify the priority topics that the WG needs to address first
-Pull together contributions by the WG though Spiral 2
++  Provide a comprehensive and ordered list of topics that must be addressed for a complete architecture
++  Identify the priority topics that the WG needs to address first
++  Pull together contributions by the WG though Spiral 2
 
 
 Plan:
-Now :  v0.1 DRAFT completed, by GPO;  see http://groups.geni.net/geni/wiki/GeniInstrumentationandMeasurementsArchitecture 
-By GEC8:  v0.5 draft, by GPO, with contributions from WG
-By GEC9:  v1.0 draft, reviewed by WG
++  Now :  v0.1 DRAFT completed, by GPO;  see http://groups.geni.net/geni/wiki/GeniInstrumentationandMeasurementsArchitecture 
++  By GEC8:  v0.5 draft, by GPO, with contributions from WG
++  By GEC9:  v1.0 draft, reviewed by WG
 
 Document outline:
-Document Scope
+1.  Document Scope
 2.  Introduction
 3.  Definition and configuration of I&M services
@@ -356 +356 @@
 
 Based on GENI I&M Capabilities Catalog (v0.1), these GENI projects have comprehensive, end-to-end capabilities:
-OML (ORBIT Measure Library) in OMF (ORBIT Mgmt Framework)  
-        (Ott, NICTA  and Gruteser, WINLAB/Rutgers, 1660)
-Instrumentation Tools 
-        (Griffioen, Univ Kentucky, 1642)
-perfSONAR for network measurements  
-         (Zekauskas, I2 and Swany, Univ Delaware, 1788)
-Scalable Sensing Service 
-        (Fahmy, Purdue and Sharma, HP Labs, 1723)
-OnTimeMeasure 
-        (Calyam, Ohio Super Ctr, 1764)
++  OML (ORBIT Measure Library) in OMF (ORBIT Mgmt Framework)  
+-  (Ott, NICTA  and Gruteser, WINLAB/Rutgers, 1660)
++  Instrumentation Tools 
+-  (Griffioen, Univ Kentucky, 1642)
++  perfSONAR for network measurements  
+-  (Zekauskas, I2 and Swany, Univ Delaware, 1788)
++  Scalable Sensing Service 
+-  (Fahmy, Purdue and Sharma, HP Labs, 1723)
++  OnTimeMeasure 
+-  (Calyam, Ohio Super Ctr, 1764)
 
 After considering projects with comprehensive, end-to-end capabilities, here are five services they have in common:
-
-Measurement Orchestration (MO) service 
-(p/o Experiment Control service, uses a language to orchestrate I&M services)
-Measurement Point (MP) service  
-(instrumentation that taps into a network and/or systems, links and/or nodes, to capture measurement data and format it using a standardized schema)
-Measurement Collection (MC) service  
-(programmable systems that collect, combine, transform and cache measurement data)
-Measurement Analysis and Presentation (MAP) service  
-(programmable systems that analyze and then present measurement data)
-Measurement Data Archive (MDA) service  
-(measurement data repository, index and portal)
++  Measurement Orchestration (MO) service 
+-  (p/o Experiment Control service, uses a language to orchestrate I&M services)
++  Measurement Point (MP) service  
+-  (instrumentation that taps into a network and/or systems, links and/or nodes, to capture measurement data and format it using a standardized schema)
++  Measurement Collection (MC) service  
+-  (programmable systems that collect, combine, transform and cache measurement data)
++  Measurement Analysis and Presentation (MAP) service  
+-  (programmable systems that analyze and then present measurement data)
++  Measurement Data Archive (MDA) service  
+-  (measurement data repository, index and portal)
 
 Expected range of implementations:  
-
-Small-scale implementations might put all I&M services within one aggregate, and even in one server
-interfaces between services would be internal to the aggregate, or even internal to the server
-
-Large-scale implementations might have I&M services distributed over many aggregates
-with measurement data flowing between services
-with orchestration mechanisms based upon message exchanges
++  Small-scale implementations might put all I&M services within one aggregate, and even in one server
+-  interfaces between services would be internal to the aggregate, or even internal to the server
++  Large-scale implementations might have I&M services distributed over many aggregates
+-  with measurement data flowing between services
+-  with orchestration mechanisms based upon message exchanges
 
 
 Discussion topics:
-Are these five services a complete group of I&M services?  
-
-Are these good names for the five I&M services?
-
-Is this five the right granularity for I&M services?
-
-Is this a complete and flexible configuration for I&M services?
-
-Can this configuration accommodate the range from small-scale to large-scale implementations?
-
-How can we obtain a consensus, so that we can set a firm foundation for the other topics?
++  Are these five services a complete group of I&M services?  
++  Are these good names for the five I&M services?
++  Is this five the right granularity for I&M services?
++  Is this a complete and flexible configuration for I&M services?
++  Can this configuration accommodate the range from small-scale to large-scale implementations?
++  How can we obtain a consensus, so that we can set a firm foundation for the other topics?
 
 Interfaces, protocols and schema for measurement data:
-
-Issues:
-This topic suggested at GEC6 meeting:  Common schema for MD
-Can we identify a common set of interfaces, protocols and schema for MD, or at least a limited number of types?
-What needs to be included in the MD schema?
-
-Approach:
-Assume all MD after MPs follows this common set of interfaces, protocols and schema
-Start with definition of MD schema
-Next, understand  [8.  MD Transport via GENI Measurement Plane]
-Then, complete first set of interfaces and protocols
++  Issues:
+-  This topic suggested at GEC6 meeting:  Common schema for MD
+-  Can we identify a common set of interfaces, protocols and schema for MD, or at least a limited number of types?
+-  What needs to be included in the MD schema?
++  Approach:
+-  Assume all MD after MPs follows this common set of interfaces, protocols and schema
+-  Start with definition of MD schema
+-  Next, understand  [8.  MD Transport via GENI Measurement Plane]
+-  Then, complete first set of interfaces and protocols
 
 From GENI I&M Capabilities Catalog (v0.1), these GENI projects (and others) are working on data schema and/or data archives:
-
-perfSONAR for network measurements   (Swany, Univ Delaware, 1788)
-IMF project  (Dutta, NC State, 1718)
-Embedded Real-Time Measurements  (Bergman, Columbia, 1631)
-GENI Meta-Operations Center  (Herron, Indiana Univ, 1604)
-netKarma:  GENI Provenance Registry  (Pale and Small, Indiana Univ, 1706)
-DatCat project at http://www.datcat.org/   (Klaffy, CAIDA)
-Crawdad project at http://crawdad.cs.dartmouth.edu/  (Kotz, Dartmouth)
-Amazon Simple Storage Service
-Data-Intensive Cloud Control   (Zink and Cecchet, UMass Amherst, 1709    )
-Experiment Mgmt System (Lannom and Manepalli, CNRI, 1663)
-others?
-
-What can we learn from these projects?
++  perfSONAR for network measurements   (Swany, Univ Delaware, 1788)
++  IMF project  (Dutta, NC State, 1718)
++  Embedded Real-Time Measurements  (Bergman, Columbia, 1631)
++  GENI Meta-Operations Center  (Herron, Indiana Univ, 1604)
++  netKarma:  GENI Provenance Registry  (Pale and Small, Indiana Univ, 1706)
++  DatCat project at http://www.datcat.org/   (Klaffy, CAIDA)
++  Crawdad project at http://crawdad.cs.dartmouth.edu/  (Kotz, Dartmouth)
++  Amazon Simple Storage Service
++  Data-Intensive Cloud Control   (Zink and Cecchet, UMass Amherst, 1709    )
++  Experiment Mgmt System (Lannom and Manepalli, CNRI, 1663)
++  others?
+-  What can we learn from these projects?
 
 Discussion topics:
-
-Standardized interfaces between measurement services
-Pt-to-pt vs pt-to-multipoint (e.g., pub/sub)
-Stream vs bulk transfer
-Disconnection operation expected, or not.
-
-Protocols for moving measurement data
-Streaming data
-Bulk-transfer of data
-
-Schema for measurement data
-Data record identifier
-Annotation, or meta data
-Data types and values, with timestamps
-
-How can we obtain a consensus on first set of intfc’s/protocols/schema for MD?
-
-What is the process for extending the set?
++  Standardized interfaces between measurement services
+-  Pt-to-pt vs pt-to-multipoint (e.g., pub/sub)
+-  Stream vs bulk transfer
+-  Disconnection operation expected, or not.
++  Protocols for moving measurement data
+-  Streaming data
+-  Bulk-transfer of data
++  Schema for measurement data
+-  Data record identifier
+-  Annotation, or meta data
+-  Data types and values, with timestamps
++  How can we obtain a consensus on first set of intfc’s/protocols/schema for MD?
++  What is the process for extending the set?
 
 
 GENI measurement plane:
-
-Issue:
-Need to understand how MD traffic flows are transported  by the GENI Measurement Plane before the interfaces and protocols for MD can be fully defined
-
-Approach:
-Understand current view of GENI Control Plane and Experiment Plane
-Consider options for GENI Measurement Plane to transport MD flows, using networks that implement GENI Control and Experiment Planes
-
-
-
-
-
-
-
-
-Priority topics: [[BR]]
-+  Common terminology;  best granularity of functions  [[BR]]
-+  Measurement data schema;  common after MPs, before and within MCs, MDAs;  what is included in meta-data?  [[BR]]
-+  Measurement Plane;  options;  expect nodes with 3 or 2 NICs  [[BR]]
++  Issue: 
+-  Need to understand how MD traffic flows are transported  by the GENI Measurement Plane before the interfaces and protocols for MD can be fully defined
++  Approach:
+-  Understand current view of GENI Control Plane and Experiment Plane
+-  Consider options for GENI Measurement Plane to transport MD flows, using networks that implement GENI Control and Experiment Planes
+
+
 
 == Next Steps for WG ==