[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[nm-wg] notes, updated charter from Network Measurements Research Group BoF, GGF11
Hi all:
here are some notes and the tentatively final charter for the NM-RG.
Notes from Notes from Network Measurements Research Group BoF, GGF 11, Hawaii
about 25 people attended. Good consensus that this RG would be useful and is needed.
Brian Tierney and Richard Hughes-Jones have volunteered to co-chair. We welcome one more co-chair
if anyone is interested.
The next step is to wait for approval from the GGF steering committee. We will use the NM-WG email for the research group until a separate mailing list gets set up.
Several people (including myself) said that they think having 2 groups named "network measurements XX" is confusing. How about "Monitoring Networks for Grip Application RG" (MN4GA-RG)? Other ideas?
-------------------
Revised Charter:
The Network Measurements Research Group (NM-RG) will focus on the relationship between network performance characteristics and Grid middleware. The objective of NM-RG is to explore what aspects of the network are most important to Grid middleware, and explore how the knowledge of network behaviour such as bandwidth, latency, or jitter, might be used to build network-aware middleware.
Specific topics of interest include, but are not limited to:
- What network characteristics are most useful to Grid Applications?
- What network characteristics are current network-aware Grid applications using/planning to use?
- Are there "derived characteristics" (combinations of characteristics) that are even more useful?
- When can passive monitoring be used, and when must active monitoring be used?
- When and how should Grid services should collect and publish passively collected network monitoring data?
- How to monitor ÒNext Generation Grid NetworksÓ.
The role of the NM-RG role is related to, yet quite distinct from that of the Network Measurement Working Group (NM-WG). The NM-WG is focused on specific mechanisms for publishing network monitoring data. The NM-RG will provide a forum for discussion of how Grid middleware might utilize such information. This is currently an open research question, and one we feel can best be addressed by the GGF. We expect any specific conclusions reached by the NM-RG to be then standardized by the NM-WG, or some other WG.
--------
Notes from Richard Hughes-Jones
Pascale: there is a need for use cases
Clarification in response to Cees: The NM-RG does not seek to make measurements or measurements systems but to use those available to provide information (eg latency, throughput, packet loss) that could be used by Grid-aware Applications.
Man from Foundry: Use of passive information such as that from imbedded network devices would be an advantage. RFC 3176 provides information on collecting information from devices. Packet sampling techniques, such as that developed in HP labs, can provide hardware data capture of frames. Several vendors are now supporting this.
Martin: CAIDA also collects network data but the focus is for network/protocol development and the data is often only available in offline modes.
Richard: we should maintain adaptively in the measurement infrastructure being aware that protocol investigations may need data at level2 ona frame by frame bases but that other applications such as brokers/schedulers may operate with average values of the network characteristics.
Paul Borrill: How does the available bandwidth affect storage performance? There are issues if the latency is large and the characteristics may vary during the day. Currently simple disks/ RAID systems limit performance but this may soon no longer be true as controllers and storage systems improve.
There may be a need for applications to access/control simple network QoS streams eg for interactive or file transfers.
Cees: Who are the customers of the NM-RG? Ans: Grid Application and Users, not network experts.
The list of topics was agreed as:
u What network characteristics are most useful to Grid Applications ?
u What Characteristics are Network aware Grid applications using at the moment?
u Are there "derived characteristics" (combinations of characteristics) that are even more useful?
u When can passive monitoring be used, and when must active monitoring be used?
u Which Grid services should collect and publish passively collected network monitoring data?
u How to monitor ÒNext Generation Grid NetworksÓ.
Documents would be informational; the following were suggested:
A. Use Cases and current use of network information.
covering:
What network characteristics are most useful to Grid Applications ?
What Characteristics are Network aware Grid applications using at the moment?
this information could be gathered by surveying Grid users/developers and outreach to other GGF groups
B. The use of Derived Characteristics, Passive Monitoring and predictive/correlations between Observations of different characteristics.
covering:
Are there "derived characteristics" (combinations of characteristics) that are even more useful?
When can passive monitoring be used, and when must active monitoring be used?
C. Monitoring ÒNext Generation Grid NetworksÓ
It was noted that Scientific groups are using grid application but there are many other application that are not yet Grid aware. This makes doc A harder! As users/developers may not know what network parameters are most useful to them.
----------------------------
Additional notes: combination of the notes taken by Brian Tierney and Martin Swany.
NMWG should do "Use cases" document: Grid applications and services
what types of Grid environments need what types of monitoring
attempt to classify types of Grids and types of applications by what
type of monitoring is needed
sample questions for the RG to address:
- How useful are the current metrics?
- can light-weight measurements accurately represent bulk transfers.
- correlation between tput and RTT?
- should analysis of network monitoring data be done by apps or middleware?
- how to combine data? "cost" functions such as "closeness"
eg: how long to move a file?
- how to combine router data? new routers have some probe ability?
- raw data vs statistically sampled techniques?
other comments from participants:
new RFC on capturing publishing network monitoring (RFC3176)
layer 2 on up to layer 4
looking at problem from a fresh perspective
need incentives to share network information
near real-time, not historical
key point: what is useful to applications
- does any of this really matter?
- how smart does the application need to me? what can be in the middleware
does a given measurement provide predictive value?
short-term prediction seems to work now, but long-range prediction still hard
Why not GHPN?
- already very broad.
Is GGF the right place? What about IETF? I2 JT?
(): it would be good in the ietf to make them aware, but not a lot of
people go to ietf in this group
(Cees): right, this is about network-aware middleware. maybe nm-wg is
even more logical for the ietf, but not this
Cees: who are the constituents? apps or networking types?
bt: half and half would be good (rhj: mixture is good)
p: should there be use-cases? (bt: 2nd bullet is about examples)
how does network bandwidth availability affect reliability of storage
systems? what does the tail look like? what is the availability of
storage over the network? what's the mtbf?
bt: related issue: what is the storage to storage bandwidth?
priority queue engine : multiple classes of transfers. like to
specify that classification in terms of what the system's priority
queue.
large, coarse classes of service that make it easy for applications to
make decisions.
Q: who are the customers? A: Grid middleware & app developers
kevin: use cases are good, but not just applications. include grid
environments -- that is important. most grid stuff doesn't run over
commercial networks
we need to talk to the networking folks and tell them what we need.
diagnostic network information for debugging is huge. martin:
performance debugging is very important.
what's the roadmap? kevin says asking the apps people what they want
is often less then ideally productive. need to as the apps folks and
then read between the lines. (asking the apps people what they want
is hard.)
don't limit it to just grid apps; any distributed adaptive application
is on the table
what if we identify new things? new derived characteristics? publish
things thru the grid? do we have to? (we don't think so...) you
don't have to publish it back, but it would be nice. particularly if
it is beneficial for others.
bt: past gridftp transfers are good predictors of future ones. it'd
be nice to share. we'd push back toward the nm-wg for actual
standards.
rhj: we will also survey all the current measurement/characterization
efforts. not just apps. but network experts and researchers.
introductions. sign up for the mailing list. announce it on the
nm-wg list. nm-wg came from performance working group and as things
have evolved, we've become more clear about the roles of rg's and
wg's.
(): for network measurements, we have to consider
security and bound the scope of the network measurement domain. (how
much data.)
rhj: security is important. ddos is possible. also on-demand
measurements have security concerns.
----------
------------------------------------------------------------------------
-------------------
Brian L. Tierney, Lawrence Berkeley National Laboratory (LBNL)
1 Cyclotron Rd. MS: 50B-2239, Berkeley, CA 94720
tel: 510-486-7381 fax: 510-495-2998 efax: 240-332-4065
bltierney@lbl.gov http://www-didc.lbl.gov/~tierney
------------------------------------------------------------------------
------------------