Minutes of the NM-WG Session 1 Tuesday 15 Oct 02

By Richard Hughes-Jones with help from the notes of George Brett.

The Agenda was agreed.

About 37 people attended the meeting, the aim being to discuss the document “A Hierarchy of Network Measurements for Grid Applications and Services”.

Bruce Lowekamp led the discussion by presenting each section of the document in turn.

Purpose of the Document

The Purpose of the document is to ensure portability and sharing of Network Measurements, given that there are many measurements frameworks, tools and APIs. The document aims to provide a common set of definitions, or a dictionary of terms, and a classification the measurements that can be made. It also defines a way to represent measurements

Basic terminology: Characteristic and Network entity.

There is now a diagram representing the relations between:

Characteristics are the intrinsic properties of the network.

Measurement Methodology – means and methods of measuring characteristics.

Observation is an instance of information obtained from a methodology.

Question: why have raw and derived characteristics?

Discussion : They come from the IPPM and seems important to maintain the difference and describe what the tool will provide (raw) and what may be calculated from possibly several different observations using different tools.

It will be useful to have both bottom up and top down views of measurements. ie what is required by Grid as well as what we can measure. Good for future work.

Network Entities

Topologies include both physical entities – actual links and nodes and functional entities – e.g. derived closeness.

Attributes are used to define the path or node for the characteristics measured. There is no distinction between links and paths. Paths may be made of components. A route is also and attribute.

Discussion of Path: Path has 2 endpoints but several attributes eg route. Paths may be made of components – each path can have “hops”.It was noted that the ATM forum also had this problem of “what is a path” suggestion to keep as simple as possible and make the definitions clear and consistent.

QoS – there are many different types so QoS could be an attribute of the Observation – a super class.

The diagram should better map onto the text here. Also just state that these are some examples only and not exclusive.

Characteristics Overview

BW: Capacity Utilisation Available

Discussion:

• Is Available the correct or most useful concept? Should there be achievable BW – this would allow for protocol overhead /CPU power /etc. This would more closely represent what an application might expect to ba able to use and would be more top down.
• There is also a problem with Wire rate BW capacity (layer1) / utilisation link layer 2 / available payload from the protocol stack layer3 – they are not fully equivalent. Don’t remove the layer dependence but state that that the 3 BW may mean different at different levels/ layers.
• Suggestion to take low level measurements and apply a transform to estimate what the user would really obtain – achievable BW.
• Achievable has to do with host performance too. But very hard to determine what any given application would get – so can only study what the protocol can deliver this is the potential the network can deliver to the application.
• Agree we need Available and Achievable.
• Encourage: define the terms then start considering the schema and tool details.

Jitter

Discussion: It was noted that jitter can be computed without one-way delay being known. UML symbols should better show the semantics of the various issues of jitter e.g. need a dotted arrow from 1-way

Loss pattern – no clear definitions yet on the way to describe loss patterns.

Discussion of Route:

• Route adds information needed for topology – an ordered set of network paths.
• Route information from BGP / routing tables is rather different from that gained from level2 (CAM) tables ie layer 2 and layer3 should be more explicit under the route.
• Practically measurements are at layer3 – layer2 is v hard and often hidden. What about lambda switching in the future.
• Agreed that “Route” is too strongly linked to layer3.

Interface: Discussion: is part of a node – not clear

Minutes of the NM-WG Session 2 Thursday 17 Oct 02

Between the two formal NM-WG meetings the document team met several times and discussed the input from the Tuesday meeting. A revised document had been made with notes in the sections indicating what should be re-worked.

Augusto Ciuffoletti presented a talk derived from work done for Grid studies in DataGrid WP7 and INFN. It presented the concept of using a functional view of the network with abstract links not physical links. See Augusto’s home page for the slides.

Discussion of the changes to the Heiarchy document

Bruce presented some slides showing the proposed changes.

A new diagram was presented of the Network entity. Inheritance of host2host path and hop has been added to network path. Hope that this representation now enables layer2 and layer3 use of hop.

Protocol stack and QoS attributes were removed as they are not the only attributes for the observation.

Nodes and paths should have physical or virtual attribute.

A new diagram was presented of the Characteristics Overview. “hoplist” replaces “route” as this is too tied to the layer3 concept. Discussed if “hoplist” is an ordered list – yes seems correct thing to do.

Routing parameters and details are under “forwarding”

Discuss if Queue measurements could be made – agree yes.

Note that some characteristics eg hoplist may be used as a related observation to a latency or BW observation.

Interface – where does the network end? Host issues are as important as net issues so the network should end in the host. Agreed to emphasise this in the doc.

What type of doc should it be?

Informational – here is something useful

Community Practice – many people believe this is the righ

Recommendation – official GGF way. 24 months call for comments

Experimental – Few weeks last call for approval. When approved, doc will be valid for ever.

Cees and Peter suggest that the document was more than just informational and should be Experimental. Later, when experience had been gained, it could be submitted as a Recommendation.

Report from the Joint NMWG / DAMED / CIM meeting

Brian Tierney reported on the joint meeting. As CIM a bit too far out it was proposed that the NW-WG should follow 2 tracks:

1. Do a sanity check referencing the tools classification. This would lead to one of our deliverables.
2. Try to use the DAMED xml work.

There is a clear need for being able to request data from various network monitoring frameworks in a consistent way. The xml would help here

There was general agreement that this was way forward but it will need formal discussion with the Area director.

Future Work of MN-MG

A mini workshop on frameworks and interoperation was proposed. This will be followed up.

Tools Document

Internet2 and SLAC already have web pages listing tools and NLANR DAST has a tool database George Brett offered to work on the classification of tools with Dan, Bruce and Richard.

Schema Document

Eric Boyd Internet2 E2Epi and Jim Ferguson NCSA offered to work on the schema with Brian to lead.

Action we will replace mailing list with the standard GGF mailing list [This has been done

The mailing list is nm-wg@gridforum.org – remember you have to subscribe.]