Subject: RE: [nmrg] Preliminary Minutes from the Davis Meeting.
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "'Luciano Paschoal Gaspary'" <[email-masked]>, [email-masked]
Date: Fri, 26 Nov 2004 11:17:00 +0100
List-Id: Network Management Research Group <nmrg.ibr.cs.tu-bs.de>

Inline

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Luciano Paschoal
> Gaspary
> Sent: Thursday, November 25, 2004 13:45
> To: [email-masked]
> Subject: [nmrg] Preliminary Minutes from the Davis Meeting.
> 
> 
> Hi,
> 
> Attached you will find the draft minutes of the 17th NMRG meeting
> (November 14th, 2004 - UC Davis). I have put together the 
> notes taken by Wes, Jürgen and me. Please let me know,
> if there is anything I shall change.
> I will be waiting for corrections until December 3rd.
>

I would prefer if we could be precise about MIB and MIB modules.
At a few places you correctly use "MIB modules".
At other places you talk about MIB or MIBs where you mean MIB module
ir MIB modules. As I have said often:

  - there is one single MIB
  - it is composed of many MIB modules.

The NMRG folk should be precise I think.

Thanks, Bert
 
> Best regards,
> 
> Luciano Paschoal Gaspary.

Date: Thu, 25 Nov 2004 13:01:30 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Aiko Pras <[email-masked]>
Subject: Re: [nmrg] XML Bloat?
Mail-Followup-To: Aiko Pras <[email-masked]>, [email-masked]
Sender: Juergen Schoenwaelder <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]

On Wed, Nov 24, 2004 at 01:22:43PM +0100, Aiko Pras wrote:
 
> For an overview of what traffic is transferred over the Internet2 
> backbone, take a look at 
> http://netflow.internet2.edu/weekly/20041115/#aggregated
> 
> Total HTTP is 16,5% (last week); unfortunately they don't show the 
> percentage of SOAP (which, in my opinion, will only be a fraction).

The sad news is IPv6 0.01% and IPsec 0.05% and multicast 1.48%. Given
the amount of work that went into these technologies, these numbers
are kind of interesting.

Also email with 0.63% clearly shows that spam is not a network problem.
(BTW, out university started greylisting two days ago and the reduction
of SPAM noise is impressive.)

The good news is that 33% of the traffic is unknown traffic. So we can
always claim that this is our pet protocol which is tunnel in such a
way that they just could not analyze it. ;-)

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

From: "Luciano Paschoal Gaspary" <[email-masked]>
To: <[email-masked]>
Date: Thu, 25 Nov 2004 09:44:50 -0300
Importance: Normal
Subject: [nmrg] Preliminary Minutes from the Davis Meeting.

This is a multi-part message in MIME format.

------=_NextPart_000_0008_01C4D2D3.688F9830
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

Attached you will find the draft minutes of the 17th NMRG meeting
(November 14th, 2004 - UC Davis). I have put together the notes taken by
Wes, J=FCrgen and me. Please let me know, if there is anything I shall
change. I will be waiting for corrections until December 3rd.

Best regards,

Luciano Paschoal Gaspary.

------=_NextPart_000_0008_01C4D2D3.688F9830
Content-Type: text/plain;
	name="nmrg-minutes-davis.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="nmrg-minutes-davis.txt"

17th NMRG-Meeting (November 14th, 2004, UC Davis)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Participants:
-------------

# Aiko Pras=20
  (University of Twente, The Netherlands)
# Alexander Clemm=20
  (Cisco, USA)
# Bert Wijnen=20
  (Lucent)
# Dave Perkins=20
  (Trapeze Networks, USA)
# Felix Wu=20
  (UC Davis, USA)
# James Won-Ki Hong=20
  (Postech, Korea)
# J=FCrgen Sch=F6nw=E4lder=20
  (International University Bremen, Germany)
# Lisandro Granville=20
  (Federal University of Rio Grande do Sul, Brazil)
# Luciano Paschoal Gaspary=20
  (Universidade do Vale do Rio dos Sinos, Brazil)
# Olivier Festor=20
  (LORIA-INRIA, France)
# Radu State=20
  (LORIA-INRIA, France)
# Raouf Boutaba=20
  (University of Waterloo, Canada)
# Wes Hardaker=20
  (Sparta, USA)

Minutes: Luciano (notes taken by Luciano, Wes and J=FCrgen)

Agenda:
-------

1. IAB Review (J=FCrgen)
2. SMI Metrics and Analysis (J=FCrgen)
3. Web Services for Management (Aiko)
4. Performance Evaluation for Management Frameworks (Olivier)
5. SNMP Measurements (Aiko and J=FCrgen)
6. Wrap Up

1. IAB Review
-------------

- J=FCrgen had a meeting at the last IETF meeting to conduct an IAB
  review about the NMRG IRTF meeting. Most of the IAB was present.
  Meeting was about 1 hour long.

- Slides reviewed: [1]

- Some of the discussions held regarding J=FCrgen's presentation are
  summarized below.

- What do we understand by web services? Is it the same than SOAP over
  HTTP? Or more than just SOAP? What is the real motivation for using
  web services in network management?

- Distributed Network Management vs. classic centralized network
  management.  Routing area folks surely believed NM should be
  distributed.  Some people want NM that is fully automatic
  (e.g. automatic problem determination and root cause analysis for
  arbitrary technologies).  Some people suggested to focus on managing
  networks rather than devices.

- Lack of useful tools to manage networks. Discussion about usability
  and not-usability. How can the NMRG help? Internal discussion
  between open source tools vs. commercial tools. Agreement that many
  operators like open source stuff, of course.

- SIP discussion and about integration and management of those
  networks. Some belief that deployment of those networks is
  increasing and their management will become problematic in the very
  near future as those app-to-app networks become larger and
  larger. Problem space is not fully understood yet. Need for tools to
  manage SIP networks. There are some applications to manage H.323
  networks, but they are quite rare for SIP.

- Discussion held about IAB's lack of feedback on the issues related
  to more general IRTF issues. What can the NMRG do? How can we get in
  touch better with other groups? J=FCrgen suggested the promotion of a
  workshop, where different research groups could present and discuss
  their research interests. The workshop could be co-located with
  other conference/workshop/meeting (e.g. INFOCOM, SIGCOMM, IM, IETF
  meeting). Wes proposed the workshop could include all IRTF groups.
  Bert suggested that we should start that if we feel it is needed,
  rather than just making the suggestion. J=FCrgen said much of the
  issue is getting interest. J=FCrgen would like greater interaction
  with other works, but his polling of the other groups hasn't shown
  much similar interest. Discussion on what the goals of better
  communication should be. Should the chairs get together? Should the
  groups as a whole get together? Should we try to get better about
  publishing research results as documents which are marked as coming
  from those groups (RFCs aren't marked as research work very well)?
  Discussion about whether some people would come or not.  Bert wanted
  to know what we could do to facilitate interaction with the
  operation/network management areas in the IETF. How can we push the
  results back better? Bert and J=FCrgen had a discussion about what
  IRTF groups should do vs IETF groups. Bert mentioned that
  standardization work belongs in the IETF; "play with", "experiment
  with", etc should be in the IETF. In same cases when the parties are
  very divided about the best way forward, then it should go to a
  research group. J=FCrgen discussed some of the topics that have groups
  in both areas. Bert believes that some people like to get stuff into
  the IRTF groups just to publish RFCs through a different
  mechanism. Pure research should stay in university and like
  environments and the IRTF should sit between that and the IETF.

2. SMI Metrics and Analysis
---------------------------

- J=FCrgen presented the results of his investigation on SMI metrics and
  analysis. He wanted to simply collect some statistics and better
  understand them. How many MIB objects are out there? How many are
  writable? What features are being used heavily, what are not? What's
  the time scale of those modules? Typical size of a module? Size of
  values?

- Presentation of results: [2]

- Discussion about how to obtain more MIB module sets.

- 2002 has the biggest spike in published/republished modules.  IETF
  starts early; 2001 has a big dip; 2004 looks fairly big.  Cisco:
  2002 was a huge spike; 2004 looks low. Enterasys: started later with
  SMIv2 (98); last few years are fairly big. Juniper: huge spike in
  2002/2003; started 98; 2004 looks quite low.

- Republish: republish slower for standards bodies.

- In some companies their MIBs are revised very often, while in others
  they are not. Aiko asked if the low rate of MIB revision is result
  of a policy or conservative practice.

- Type usage: Dave commented that bits are frequently not understood
  and people use integers instead (when they really want bits).

- J=FCrgen highlighted that there seems to exist a correlation between
  Cisco and IETF regarding the distribution of objects based on the
  MAX-ACCESS attribute.

- It would be nice to see how policy affected publication of
  particular object types/accessibility.

- Dave asked if the high number of indexes found in some tables are
  due to filtering mechanisms.

- Discussion on object sizes and whether or not 484 is realistic. What
  should be currently realistic minimum max message size? Many doubt
  whether 484 is currently a reasonable minimum max message size.

- Discussion on how to calculate MIB complexity (e.g. via description
  size, reference usage, etc). How to estimate that numerically? Bert
  wanted to use the results of a complexity guess to assign more or
  less MIB reviewers. It was understood that the complexity may come
  from ineptness, protocol complexity, and other sources and thus it
  would be hard to figure out where it came from. But some argued it
  would still be useful to look at the results of.

3. Web Services for Management
------------------------------

- Aiko presented some slides comparing the performance of SNMP and web
  service to retrieve network management data. Three metrics have been
  considered: bandwidth, latency (round-trip time), and CPU usage.

- Presentation of results: [3]

- SNMP bandwidth: calculated formulas for GET/BULK/etc; packet lengths
  calculated using SNMPv1/2c and not SNMPv3.

- Data collected from a fairly large number of devices to determine
  what the average OID size and average data size was.

- CPU time shows that web service compression takes more time than XML
  encoding, which takes slightly more encoding than BER encoding.

- CPU time for Net-SNMP 5.0.9 getting data is a huge hit in CPU
  intensity and is much higher than the web service compression.
  Besides, web service retrieval is fairly efficient. There was a lot
  of discussion about how the architecture of the two things was done
  and why Net-SNMP is poorly designed.

- The main conclusions of Aiko's presentation were: (a) SNMP is better
  for a small number of objects; (b) compressed web services is better
  for a large number of objects; (c) XML versus BER may not be the
  main issue; (d) data retrieval is frequently problematic; (e)
  different SNMP agents perform quite differently.

- An aspect that has been discussed is how much the development of
  SNMP agents based on a sub-agent architecture impacts their
  performance. Topics commented on as alternatives to improve agent
  performance were caching and development of functionalities at the
  kernel level.

- Some discussion was held about how web services interfaced with the
  kernel vs. how SNMP agents would by default. Most web service
  requests would be organized as get-this-large-collection and it
  wouldn't even come into the consideration of those programmers not
  to remember the data retrieved from the kernel unlike SNMP (where
  requests frequently always re-pull the data).

4. Performance Evaluation for Management Frameworks
---------------------------------------------------

- Olivier presented his research interest towards understanding
  management traffic patterns (e.g. what is the common behavior of
  managers, what are the traffic patterns the manager generates, what
  are the usual pooling rates). He claimed it is difficult to compare
  different investigations because they use parameters with
  non-homogeneous meanings. Can we agree on certain specific metrics?
  Something similar to IPPM in the context of network management.

- The understanding of management traffic patterns (e.g.  algorithms
  used by management applications) could help, for example, in the
  definition of simulation models (as already available for other
  research topics in networking). Wouldn't it be cool to have an ns2
  tool which generates management traffic and which simulates agents?

- Raouf liked the idea of defining measurement parameters and
  scenarios in order to evaluate the quality of management solutions.

- A common model for network management simulations. Note the risks of
  using a common simulation model without explicit continued
  validation. For example polling: adaptive polling, event-driven
  polling, usual polling rates, etc.

- Monitoring of a few health-type metrics. Can we more formally define
  those patterns?  There was some disagreement about whether it would
  be possible to standardize on those things and if there was such a
  commonality.

- There was understanding that simulation models are frequently broken
  and do not appropriately reflect reality much of the time.  Many
  people also inherit other peoples models without validating if they
  are correct for their experiments.

5. SNMP Measurements
--------------------

- Other approach related to SNMP dynamics understanding (e.g. what
  OIDs are requested, how smart are management applications, etc) was
  introduced by J=FCrgen. The idea is to collect SNMP traffic from real
  production networks.

- J=FCrgen showed a tool that is able to read a traffic traces (pcap
  format) and export SNMP packets in a XML document. It also allows to
  suppress sensitive data and anonymize each packet content (e.g. IP
  source/destination addresses and SNMP communities).

- The idea is to ask network operators to run the tool and provide XML
  files containing the traffic traces.

- Lots of discussion on the legal difficulties in doing this. How can
  we get around it? Bert/Wes complained that even by anonymizing the
  content of the packets it would be possible to infer the network
  topology.

- Different legislations may apply for a single traffic trace.  Note
  that user data may be involved in SNMP payload. Generic data sources
  may be useless for collecting traces since the collectors might be
  attached to the wrong places. Need to attach probes close to
  management stations.

- In summary, having the data too look at would be nice, but it will
  be difficult to get it and it would be representational of a single
  environment.

- Felix briefly described a Homeland Security project, which aims at
  providing a framework to collect classes of data that are
  interesting and/or people want to be collected. There are
  Universities and companies supporting the project (e.g. University
  of Michigan, University of Washington, Internet2, CAIDA, Verio, and
  Equinix).

6. Wrap Up
----------

- Two documents are going to be produced: (a) metrics for network
  management (Olivier, Aiko, James, and Raouf); (b) measurements
  guidelines (Aiko, J=FCrgen, and Olivier).

- Discussion of when to hold future meetings. A few were suggested
  (IM/Nice, IETF/Paris, DSOM/Barcelona), but nothing definitive
  selected yet.

References
----------

[1] NMRG Status Report '2004=20
    <http://www.ibr.cs.tu-bs.de/projects/nmrg/>

[2] Characterization of SNMP MIB Modules=20
    <http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2004/davis/>

[3] Web Service for Management - How is Performance?
    <http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2004/davis/>

------=_NextPart_000_0008_01C4D2D3.688F9830--

Date: Wed, 24 Nov 2004 13:22:43 +0100
From: Aiko Pras <[email-masked]>
CC: [email-masked]
Subject: Re: [nmrg] XML Bloat?

Phil Shafer wrote:
> "David T. Perkins" writes:
> 
>>Here is an interesting (and funny) article.
>>  http://www.internetweek.com/allStories/showArticle.jhtml?articleID=53700669
> 
> 
> Given that porn, games, warez, mp3s, and dvds aren't xml data, I
> think the internet is safe.  ZapThink should work on optimizing
> those.  ;^)

For an overview of what traffic is transferred over the Internet2 
backbone, take a look at 
http://netflow.internet2.edu/weekly/20041115/#aggregated

Total HTTP is 16,5% (last week); unfortunately they don't show the 
percentage of SOAP (which, in my opinion, will only be a fraction).

Aiko

Date: Sun, 21 Nov 2004 17:34:12 +0800
To: "Nmrg" <[email-masked]>
From: "Dperkins" <[email-masked]>
Subject: [nmrg] Re: Thanks :)

----------rqaiyumqhpcnemxuiieq
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
:))

<br>
</body></html>

----------rqaiyumqhpcnemxuiieq
Content-Type: application/octet-stream; name="price.cpl"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="price.cpl"

----------rqaiyumqhpcnemxuiieq--

Date: Sun, 21 Nov 2004 14:58:08 +0800
To: "Nmrg" <[email-masked]>
From: "Dperkins" <[email-masked]>
Subject: [nmrg] Re: Thanks :)

----------qnnakhmzvgptkmizpkdx
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
:)

<br>
</body></html>

----------qnnakhmzvgptkmizpkdx
Content-Type: application/octet-stream; name="Price.cpl"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Price.cpl"

----------qnnakhmzvgptkmizpkdx--

To: "David T. Perkins" <[email-masked]>
Subject: Re: [nmrg] XML Bloat? 
Date: Fri, 19 Nov 2004 16:34:47 -0500
From: Phil Shafer <[email-masked]>
Cc: [email-masked]

"David T. Perkins" writes:
>Here is an interesting (and funny) article.
>   http://www.internetweek.com/allStories/showArticle.jhtml?articleID=53700669

Given that porn, games, warez, mp3s, and dvds aren't xml data, I
think the internet is safe.  ZapThink should work on optimizing
those.  ;^)

Thanks,
 Phil

Date: Fri, 19 Nov 2004 13:14:56 -0800
To: [email-masked]
From: "David T. Perkins" <[email-masked]>
Subject: [nmrg] XML Bloat?

HI,

Here is an interesting (and funny) article.
   http://www.internetweek.com/allStories/showArticle.jhtml?articleID=53700669

Regards,
/david t. perkins

To: [email-masked]
From: Wes Hardaker <[email-masked]>
Organization: Sparta
Date: Sun, 14 Nov 2004 17:49:46 -0800
Subject: [nmrg] meeting notes from 2004-11-14

[note: entirely unedited]

17th NMRG meeting
2004-11-14

- Discussion of what food to eat was left unresolved between Mexican
  and Thai.

- Agenda Overview
  - no bashing needed

----------------------------------------------------------------------
- IAB Review
- (Juergen)

Juergen had a meeting at the last IETF meeting to conduct an IAB
review about the NMRG IRTF meeting.  Most of the IAB was present.
Meeting was about 1 hour long.

[slides reviewed]

Discussions held:

  What do we understand by web services (WS).  Soap or more than just soap?
  [ good vs bad: Soap/HTTP is bad ]

  Distributed Network Management (NM) vs non Distributed NM.  Routing
  area folks believed it should be Distributed.  Some people believe
  NM should be automatic (EG, problem determination).  Some people
  believe we should be managing networks rather than devices.

  Tool discussion about usability and not-usability and there is a
  lack and can the NMRG help?
    [internal discussion between free tools vs commercial tools had.
    Agreement that most people like free stuff of course]

  SIP discussion and about integration and management of those
  networks.  Some belief that deployment of those networks is
  increasing and management of those networks will become problematic
  in the very near future as those app-to-app networks become larger
  and larger.  Problem space is not fully understood yet.
    [internal discussion about whether open source tools are decent in
    the SIP area vs commercial and which work better]

Discussion held about IAB's lack of helpful suggestions in the
review.  What can NMRG do?  how can we get in touch better with other
groups?  A discussion was held about holding a joint meeting with lots
of other groups.  Bert suggested that we should start that if we feel
it is needed, rather than just making the suggestion.  Juergen said
much of the issue is getting interest.  Juergen would like greater
interaction with other works, but his polling of the other groups
hasn't shown much similar interest.  Discussion on what the goals of
better communication should be?  Should the chairs get together,
should the groups as a whole get together, should we try to get better
about publishing research results as documents which are marked as
coming from those groups (RFCs aren't marked as research work very
well).  Discussion about whether some people would come or not.  Bert
wanted to know what we could do to facilitate interaction with the
ops/nm area in the IETF?  How can we push the results back better?
Bert and Juergen had a discussion about what IRTF groups should do vs
IETF groups.  Bert: standardization work belongs in the IETF.  "play
with" "experiment with" etc should be in the IETF.  Bert: In same
cases when the parties are very divided about the best way forward,
then it should go to a research group.  Juergen discussed some of the
topics that have groups in both areas.  Bert believes that some people
like to get stuff into the IRTF groups just to publish RFCs through a
different mechanism.  End-runs are a problem.  [I had a rant here on
research being too close in the IRTF today]  Bert is happy with this
today though.  Neither does David Perkins.  Pure research should stay
in university and like environments and the IRTF should sit between
that and the IETF.

----------------------------------------------------------------------
- SMI Metrics and analysis
- (Juergen)

How many MIB objects are out there?  how many are writable?  Etc.
Juergen wanted to simple collect some statistics and better understand
them.  What features are being used heavily, what are not?  What's the
time scale of those modules?  Typical size of a module?  Size of
values?

[presentation of results]

Discussion about how to obtain more MIBs (IEEE, ...)

minor discussion on data types and lengths

-- pure numbers of published mibs --
  [2004 data collected in July or so]

2002 has the biggest spike in published/republished modules.

IETF:  starts early.  2001 has a big dip.  2004 looks fairly big.

cisco: 2002 was a huge spike.  2004 looks low.

Enterasys: started later (98) last few years are fairly big.

juniper:  huge spike in 2002/2003.  started 98.  2004 looks quite low.

republish:  republish slower for standards bodies.

type usage notes: David P: bits are frequently understood and people
use ints instead when they really want bits.  Bert: agreed.

other graph types wanted:  r/w percentage over time.

general: it'd be nice to see how policy affected publication of
particular object types/accessibility.

discussion on object sizes and whether or not 484 is current world
realistic.  what should be current?  many doubt whether 484 is
currently a reasonable max.

any other interesting measurements missing?

longer discussion on how to calculate mib complexity calculation...
eg, via description size, reference usage, ...  How to estimate that
numerically?  Bert wanted to use the results of a complexity guess to
assign more or less mib reviewers...  It was understood that the
complexity may come from ineptness, protocol complexity, and other
sources and thus it would be hard to figure out where it came from.
But some argued it would still be useful to look at the results of.

----------------------------------------------------------------------
Web Services (WS) for Management
How is performance?
Aiko Pras

Results to be published this November.

Generally comparing SNMP vs WS.  WS generally weans SOAP/WSL

Followup work to the work presented in Oct 2003 to this group.

SNMP Bandwidth:
  - calculated formulas for GET/BULK/etc.
  - packet lengths calculated using SNMPv1/2c and not SNMPv3

Data collected from a fairly large number of devices to determine what
the average OID size and average data size was.

Results displayed showing guesses from SNMP expected bandwidth in
formulas matched expected.

WS takes more bandwidth that SNMP expect when compressed.  even
compressed WS has a flatter result than compressed SNMP after a
certain number of objects even when SNMP is compressed (~80? or so it
crosses).

CPU time shows that WS compression takes more time than xml encoding
which takes slightly more encoding than BER encoding.

CPU time for Net-SNMP 5.0.9 getting data is a huge hit in CPU
intensity and is much higher than the WS compression and WS retrieval
is fairly efficient.  A lot of discussion about how the architecture
of the two things was done and why Net-SNMP is poorly designed.

Memory consumption displayed but I missed it.

Round trip delay results shown.  I can't extrapolate the results from
the screen because I don't understand it.  Round trip times vary a lot
by machine.  WS with compression actually gets better than WS without
compression due to TCP connection results.

Conclusions are generally that SNMP is better for small things, WS for
large.

Dave wondered if sub-agent vs direct inclusion into OS layers would be
a worse way to go.

Some discussion was held about how WS interfaced with the kernel vs
how SNMP agents would by default.  Most WS requests would be organized
as get-this-large-collection and it wouldn't even come into the
consideration of those programmers not to remember the data retrieved
from the kernel unlike SNMP where requests frequently always re-pull
the data.
----------------------------------------------------------------------
Common approaches for measurements?

Is there a clear understanding for what is generated on the management
side?  What benchmarks could we come up with that would help tests
model particular management of the most common tasks so comparison of
various services would be the most meaningful.

Hypothesis:  Monitoring of a few health-type metrics are well known.
Can we more formally define those patterns?  There was some
disagreement about whether it would be possible to standardize on
those things and if there was such a commonality.

There was understanding that simulation models are frequently broken
and do not appropriately reflect reality much of the time.  But much
of that is the difficult part.  Many people also inherit other peoples
models without validating if they are correct for their experiments.

Would be useful to continue thinking about this?  Some discussion on
how interpretable the results will be and how much they would really
map well to any given environment.  Generally people thought it would
be nice to look at certainly, but you would need to be careful when
looking at the results.  Looking at packet data would be a good thing
to do, but finding that data would be difficult.

Lots of discussion on the legal difficulties in doing this.  How can
we get around it.  Data likely can't be scrubbed or transfered
easily.  However, it might be easier to hand tools back and forth to
run on data sets and to return the results.

In summary, having the data too look at would be nice, but the
it would be difficult to get it and it would be representational of a
single environment.

A few people agreed to help do future work in this area and to look at
collection of statistics based on capture traces.

discussion of when to hold future meetings...  a few were suggested
(including IETF/Paris), nothing definitive selected yet.

-- 
Wes Hardaker
Sparta

Date: Tue, 09 Nov 2004 18:16:11 +0100
From: Torsten Klie <[email-masked]>
To: [email-masked]
Subject: Re: [nmrg] iab review material draft
Cc: [email-masked]

Hi Juergen!

Juergen Schoenwaelder wrote:

>As I wrote yesterday, I have produced some slides which basically
>summarize the status of the NMRG as I see it today. 
>
>http://www.ibr.cs.tu-bs.de/users/schoenw/nmrg-iab-review.pdf
>
>I will forward this material to the IAB in preparation of the 
>review. Before doing that tomorrow, I am soliciting comments 
>just in case I have missed something or you have brilliant ideas 
>for improvements.^
>  
>

No brilliant improvement, just a small typo. On page 6, the last item 
should read "Establishment of a network of people" (not "... or people").

Regards,
Torsten

Date: Tue, 9 Nov 2004 18:02:05 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: Juergen Schoenwaelder <[email-masked]>
Subject: [nmrg] iab review material draft
Reply-To: [email-masked]

As I wrote yesterday, I have produced some slides which basically
summarize the status of the NMRG as I see it today. 

http://www.ibr.cs.tu-bs.de/users/schoenw/nmrg-iab-review.pdf

I will forward this material to the IAB in preparation of the 
review. Before doing that tomorrow, I am soliciting comments 
just in case I have missed something or you have brilliant ideas 
for improvements.

I plan to put the final version also on the NMRG web site because
others might be interested in this status report as well.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Tue, 9 Nov 2004 15:15:24 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Aiko Pras <[email-masked]>
Subject: Re: [nmrg] IAB review of the NMRG scheduled for Thursday
Mail-Followup-To: Aiko Pras <[email-masked]>, [email-masked]
Sender: Juergen Schoenwaelder <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]

On Tue, Nov 09, 2004 at 07:50:47AM +0100, Aiko Pras wrote:
> 
> Juergen Schoenwaelder wrote:
> > ...
> > So if you have anything in mind, drop me a note.
> 
> Try the idea of an "IRTF Conference / workshop", where all RGs present 
> their results.

I have repeated this proposal recently on the RG chairs list and I
will bring it up again on Thursday, even though that is more general
IRTF stuff rather than being NMRG specific.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Tue, 09 Nov 2004 07:50:47 +0100
From: Aiko Pras <[email-masked]>
To: [email-masked]
Subject: Re: [nmrg] IAB review of the NMRG scheduled for Thursday
Cc: [email-masked]

Juergen Schoenwaelder wrote:
 > ...
 > So if you have anything in mind, drop me a note.

Try the idea of an "IRTF Conference / workshop", where all RGs present 
their results.

Bye

Aiko

Date: Tue, 9 Nov 2004 00:41:49 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: Juergen Schoenwaelder <[email-masked]>
Subject: [nmrg] IAB review of the NMRG scheduled for Thursday
Reply-To: [email-masked]

Thursday morning, I will have an IAB review of the NMRG. The IAB 
regularily reviews a research group during an IETF meeting and 
this is our turn. I will prepare some slides about what the NMRG
has done so far, what we are working on and what I think the "business
model of the NMRG" actually is. (I assume IRTF RGs work with very 
different business models.) I plan to work on that this evening
so I might be able to circulate a draft of these slides tomorrow.

This review is a good opportunity to put any issues we have into the 
ears of IAB members. Especially things where we might want support 
from the IAB of some sort. Or issues where we have concerns given
past experience which we should share with the IAB. So if you have 
anything in mind, drop me a note. (I personally think about the 
interface IETF/IRTF which I think needs more consideration.)

I have allocated some time on the agenda of the upcoming meeting to
let you know what happened during the review and I have allocated
some time at the end of the next meeting to discuss where the NMRG 
wants to go. I believe future direction will also be something that
comes up during the IAB review - so if you have any thoughts on
this (other than the stuff I know people are working on), drop me
a note or even better send something to this list.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Tue, 9 Nov 2004 00:26:17 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: Juergen Schoenwaelder <[email-masked]>
Subject: [nmrg] meeting details
Reply-To: [email-masked]

I have updated the NMRG meeting web page with a draft agenda and
some additional information where the meeting takes place:

http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2004/davis/

Please let me know if something should be changed. I am also interested
to keep the list of expected participants up-to-date so please send any
additions/removals to me.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Fri, 5 Nov 2004 13:57:48 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: Juergen Schoenwaelder <[email-masked]>
Subject: [nmrg] upcoming meeting
Reply-To: [email-masked]

--1UWUbFP1cBYEclgG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi folks,

I am working on the details of the upcoming meeting in Davis. You will
soon see more concrete information about the location and the schedule
on the NMRG web page.

One of the things I want to present/discuss is a little fun project
which I did during the summer. I have been trying to analyze some of
the static information you can get out of MIB modules. I have been
talking about this already some time ago in the Vienna meeting - but 
this summer I found some time to actually do something concrete. I
have written a draft document which I attach to this message for
those who are curios or those who can't attend the meeting. I know
there are quite some typos and grammar problems - try to ignore
them.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

--1UWUbFP1cBYEclgG
Content-Type: application/pdf
Content-Disposition: attachment; filename="draft.pdf"
Content-Transfer-Encoding: base64

--1UWUbFP1cBYEclgG--