Subject: RE:charter goal 2

From: "ELAINE SHARP" <[email-masked]>
Date: Mon, 5 Feb 2001 14:22:00 -0500

Please remove my name from your mailing list.
Thanks

[email-masked]

------------------( Forwarded letter 1 follows )--------------------
Date: Mon, 5 Feb 2001 17:37:51 +0100
To: Nevil.Brownlee[n.brownlee]@auckland.ac.nz.inet,
 [email-masked]
From: Kappler.Cornelia[Cornelia.Kappler]@icn.siemens.de.inet
Sender: [email-masked]
Subject: charter goal 2

>  2 Define a distributed metering architecture to support metrics
>    defined within the IPPM framework, e.g. one-way delay,
>    connectivity, one-way loss rate.  This architecture will
>    include remote packet capture, and will addres privacy
>    concerns such as the inadvertant disclosure of user
>    information and the need to authenticate and authorise
>    access to captured data.
>
>
So I figure the distributed metering architecture is necessary for supporting the metrics of ippm. However, there seem to be more reasons for developing it, such as remote packet capture. The benefit of the latter is improved processing performance (?).
 Therefore the goal should be re-formulated along the lines. E.g.

"Define a distributed metering architecture. Such a distributed architecture would on the one hand support metrics based on distributed measurements such as those developed by the ippm. On the other hand, it would support remote packet capture, with the
 benefit of improved metering performance." (I'm not sure I grasp the full benefits of remote packet capture.)

The other thing I dislike about this goal is that rtfm IS already distributed: Many meters can report to a single reader. The reason ippm metrics cannot be supported is that readers don't do any processing, at least not any that is standardized. So I
 would like to discuss whether "distributed metering architecture" is indeed the correct term. What we are rather doing is introducing yet another layer in the measurement hierarchy.

Finally, remote packet capture is possibly another form of distributed metering than that needed for ippm metrics. For ippm metrics you necessarily have a n:1 relation beween points of measurement and meters. With remote packet capture, you might just
 have a 1:1 relation. So may be remote packet capture should be a separate goal.

Cornelia

--------------------
Cornelia Kappler
Standards & Technology
ICM N MC ST3
Siemens AG, Siemensdamm 62, 13629 Berlin, Germany

---

From: "ELAINE SHARP" <[email-masked]>
Date: Tue, 6 Feb 2001 08:47:00 -0500

Would you mind removing my name from your email list  please!
Thanks!
[email-masked]
------------------( Forwarded letter 1 follows )--------------------
Date: Mon, 5 Feb 2001 15:48:55 -0500
To: Kappler.Cornelia[Cornelia.Kappler]@icn.siemens.de.inet,
 Nevil.Brownlee[n.brownlee]@auckland.ac.nz.inet,
 [email-masked]
From: Carter.Bullard[carter]@qosient.com.inet
Sender: [email-masked]
Reply-To: [email-masked]
Subject: RE: charter goal 2

Hey Kappler,
   I believe that distributed monitoring pertains to
metrics that can only be determined through the use
of multiple monitors measuring the same network event.

One-way delay is a great example of this.  You have to
have time determination at two points along the path.
Some packet loss metrics can only be measured with two
meters, and some reachability metrics require two meters.
Connectivity monitors in asymmetric networks require
multiple monitors.

   I see Remote Packet Capture as supporting distributed
monitoring, rather than distributed monitoring enabling/
supporting Remote Packet Capture.  Remote packet capture
enables a single meter to monitor at multiple points in the
network at the same time.  Remote packet capture is not a
meter, it is merely a tap, that can support any kind of
meter you want to build (assuming its a packet meter ;o).

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

[email-masked]
Phone +1 212 813-9426
Fax   +1 212 813-9426

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Kappler Cornelia
> Sent: Monday, February 05, 2001 11:38 AM
> To: 'Nevil Brownlee'; [email-masked]
> Subject: charter goal 2
>
>
>
>
> So I figure the distributed metering architecture is
> necessary for supporting the metrics of ippm. However, there
> seem to be more reasons for developing it, such as remote
> packet capture. The benefit of the latter is improved
> processing performance (?). Therefore the goal should be
> re-formulated along the lines. E.g.
>
> "Define a distributed metering architecture. Such a
> distributed architecture would on the one hand support
> metrics based on distributed measurements such as those
> developed by the ippm. On the other hand, it would support
> remote packet capture, with the benefit of improved metering
> performance." (I'm not sure I grasp the full benefits of
> remote packet capture.)
>
> The other thing I dislike about this goal is that rtfm IS
> already distributed: Many meters can report to a single
> reader. The reason ippm metrics cannot be supported is that
> readers don't do any processing, at least not any that is
> standardized. So I would like to discuss whether "distributed
> metering architecture" is indeed the correct term. What we
> are rather doing is introducing yet another layer in the
> measurement hierarchy.
>
> Finally, remote packet capture is possibly another form of
> distributed metering than that needed for ippm metrics. For
> ippm metrics you necessarily have a n:1 relation beween
> points of measurement and meters. With remote packet capture,
> you might just have a 1:1 relation. So may be remote packet
> capture should be a separate goal.
>
> Cornelia
>
>
> --------------------
> Cornelia Kappler
> Standards & Technology
> ICM N MC ST3