# Presentation: 388207

## GGF10, Berlin, March 2004

**Request Schema****Network Measurements Working Group**

- Mark Leese

- Paul Mealor

- R. Hughes-Jones    ICFA Meeting    CERN    Nov 1999

## Contents

- History				PAST
- Where we are			PRESENT
- What next				FUTURE

- R. Hughes-Jones    ICFA Meeting    CERN    Nov 1999

## History 1

- Once upon a time (June 2003) there was a publication schema for returning and sharing network measurement data
**Aims:** to standardise communication, **and**...
- ...use XML, for web services and OGSI model
- One _possible_ use case:

- perf database

**More Info: **Dan’s presentation

- R. Hughes-Jones    ICFA Meeting    CERN    Nov 1999

## History 2

- But the publication schema was very lonely...
- ...until October ‘03 (GGF10) when suggestion was made for producing a unified way of asking for data and tests
- _Simple_ use case:

- Network Monitoring Service

- R. Hughes-Jones    ICFA Meeting    CERN    Nov 1999

## History 3

- Working group began after GGF, with input from:
- Loukik Kudarimoti & Nicolas Simar, DANTE
- Mark Leese, Daresbury Laboratory
- Warren Matthews, Georgia Tech
- Jeff Boote, Eric Boyd & Matt Zekauskas, Internet2
- Dan Gunter, Lawrence Berkeley
- Tanya Brethour, NLANR
- Paul Mealor, University College London

- R. Hughes-Jones    ICFA Meeting    CERN    Nov 1999

## Where we Are 1

- Schema requirements set. Implementations in:
- W3C schema language (WXS)
- OASIS’ Relax NG
- Four sections: what, where, when, how
- _What_:
- Use DAMED style names, e.g. path.delay.oneWay
- Can request statistical data, with a specified sample interval, e.g. daily averages for one-way delay over the last month
- Single characteristics (for now), but multiple statistics
- Can limit number of returned results to avoid overload

- R. Hughes-Jones    ICFA Meeting    CERN    Nov 1999

## Where:
Source and destination
Flexible: IPv4|6, hostnames, or textual names such as “core router” and “edge router” (e.g. for security)
When:
Primary means of specifying the time period we are interested in (for tests or data retrieval) is:
target Time (an absolute time or “now”)
relative +ve and -ve time tolerances...
		-ve time tolerance	= 600 secs
		target_time		= 14:00
		-ve time tolerance	= 600 secs

- Source and destination
- Flexible: IPv4|6, hostnames, or textual names such as “core router” and “edge router” (e.g. for security)
- _When_:
- Primary means of specifying the time period we are interested in (for tests or data retrieval) is:
- target Time (an absolute time or “now”)
- relative +ve and -ve time tolerances...
- 		-ve time tolerance	= 600 secs
- 		target_time		= 14:00
- 		-ve time tolerance	= 600 secs

**Where we Are 2**

- R. Hughes-Jones    ICFA Meeting    CERN    Nov 1999

## Where we Are 3

- Setting limit on number of results controls possibilities:
- when number of results = “all”: supply all matching measurements in given time period
- when number of results = 1: time data defines the period for which a measurement is considered to be _acceptable_, e.g. 14:00 +/- 10 minutes
- “now” evaluated as late as possible, to avoid problems with transmission and processing delays
- absolute time format: secs from 1/1/1970, XML or NTP
- Can also give start & end time if you wish, but values are mapped to target_time & number of results will = all
- “testing interval” controls how often tests are run

- R. Hughes-Jones    ICFA Meeting    CERN    Nov 1999

## Where we Are 4

- _How_:
- Can supply values to act as parameters for tests, or filters for querying past data, including tool name.
- Uses param specific tags or list of parameters:
- <remoteParamList>-a –b 10 -c</remoteParamList>
- Possible to set ranges for parameters...
- 		<tcpBufferSize range=“max”>4194304</tcpBufferSize>
- 		<tcpBufferSize range=“min”>1048576</tcpBufferSize>
- 	...and orders of preference.
- Unspecified params use receiving system’s defaults
- Can request reporting of actual param values used
- Can control whether a test is ever run

- R. Hughes-Jones    ICFA Meeting    CERN    Nov 1999

## What Next 1

- Unsurprisingly, request and publication schemas contain similar sections, e.g. src & dest address
- Sensible to identify and abstract commonalities:

- src & dest

- src & dest

- R. Hughes-Jones    ICFA Meeting    CERN    Nov 1999

## What Next 2

- In practice, request and publication schemas are likely to be insufficient.
- Take for example:
- Interim schemas may therefore be required.

- responder

- R. Hughes-Jones    ICFA Meeting    CERN    Nov 1999

## What Next 3

- Outstanding issues, _one_ example:
- GHPN-RG “Grid network services” working draft talks of prediction service. How do we support requests?

- A: extend schema for predictions

- B: send request to specific service

**Or BOTH?**

- R. Hughes-Jones    ICFA Meeting    CERN    Nov 1999

## Conclusion

- Produced request schema to complement publication schema
- Requirements document available on GridForge
- WXS and Relax NG versions available
- TO DO:
- Identify commonalties of both schemas
- Produce “pool” of common components, shared by “skeleton” versions of both schemas
- Interim schemas
- Resolve issues, e.g. requests for predictions
**>>> **Trial in Grid network monitoring services **<<<**

- R. Hughes-Jones    ICFA Meeting    CERN    Nov 1999

## 

Questions

m.j.leese@dl.ac.uk                    pdm@hep.ucl.ac.uk

[source forge address]

- Questions
- _[m.j.leese@dl.ac.uk](mailto:m.j.leese@dl.ac.uk)_                    _[pdm@hep.ucl.ac.uk](mailto:pdm@hep.ucl.ac.uk)_
- [source forge address]

**The ****End**

- R. Hughes-Jones    ICFA Meeting    CERN    Nov 1999