[Mtools-report] Getting started again

Fri Oct 12 23:24:04 PDT 2007

Excellent point with regard to the other types of packets.  We should
probably consider the questions for each of the packet types mentioned with
acceptance that multicast and broadcast traffic are in many ways less
measurable.  For example, I don't think we can talk about RTT for multicast
or broadcast traffic, nor do I think we will find that the same tool base is
available.

Would we want separate graphs for IPv4 and IPv6 packets?

I like the idea of adding to cricket the measurement and graphing of
multicast and broadcast pps rates.  Would there be a need for refining and
reporting of this data beyond the cricket graphs?  Continuing with the
unicast, multicast, broadcast line of thought would a report showing the
change in the ratio of unicast, multicast, and broadcast pps or bps over time
on the backbone links be useful enough to investigate what it would take to
automatically extract and generate such a report from cricket data?  I am not
sure that the value of the data in this case justifies the effort, but in
other situations it probably does and is what I think we need to tackle in
question (3).

Finally, I think we should schedule a conference call for the group and see
who can make it.  Chances are that this timeframe is too short, but who can
make:

10/16/2007 at 1pm or 2pm or 3pm or 4pm

Otherwise, perhaps we can try to schedule the date and time for the
conference call at the 10/18 HPR-TAC.

Jeremy Powell

________________________________

From: John Haskins [mailto:jah at ucsb.edu]
Sent: Thu 10/11/2007 2:13 PM
To: Jeremy Powell
Cc: mtools-report at lists.cenic.org
Subject: Re: [Mtools-report] Getting started again

Jeremy, thanks for trying to wake us up, we have been pretty quiet eh? 

I think your list is a great starting point. 

I'd like to add a specific item that I think might be low-hanging fruit.

On the existing cricket graphs (http://cricket.cenic.org/grapher.cgi) only
unicast packet counts are represented.  I'd like to suggest that all
interface PPS collections include the OIDs for unicast, multicast, and
broadcast packet counts, and that perhaps this could be done as soon as it
can be fit into the queue of the cricket herder.

I think we should keep in mind a requirement to watch other than IPv4 unicast
traffic when we consider tools to look at utilization.

-john

on 9/28/2007 14:53 Jeremy_Powell at sbcss.k12.ca.us wrote:
> While many have seen the following documents a couple of times recently,
> others have not:
>
>
http://tac.cenic.org/priv/dctac20070927/initiative_description_2006-12-06.pdf
>
http://tac.cenic.org/priv/dctac20070927/measurement%20tools%20list-current.do
c
>
> They include the Measurement Tools and Reporting Initiative description and
> tools of interest identified so far.  The name of our discussion list is
> mtools-report at lists.cenic.org.  Before trying to schedule some time for a
> video or audio conference, it would be good to try to come up with some
idea
> of:
>
> 1) What do we want to measure?  Thinking in terms of specific metrics, my
> initial list would be:
>
> Latency - round trip one way
> Jitter - variation in round trip of one way latency
> Loss
> Percent of capacity utilized
> Change in those values over time
>
> In addition, do we want to think about any sort of alert/notification if
> those values or a combinatin of those values exceed certain thresholds.
>
> 2) What is the scope/scale of measurement.  This may depend both on the
> particular value measured and the tools available for measuring it.  My
goal
> would be to measure each of the above values across the backbone and to
each
> connected campus or k12 node site.  I think this is on the order of 300
> locations.  I am not sure how to address peer connections or if this is a
> concern to address or not.  My guess is that:
>
>       a) For HPR connections some of this is already being done by the HPR
> Perfomance and Measurement initiative.
>
> http://tac.cenic.org/priv/HPR-Perf-Testing-Board-Presentation.pdf
> http://tac.cenic.org/priv/HPR-Perf-Testing-Proposal.pdf
>      
>       b) For the backbone some of this is already being done by the
> measurement infrastructure in place for the SLA reporting.
>
> http://www.cenic.org/calren/CENIC_SLA_Report.pdf
>
> 3) What do we want to report and to whom?  What should that report look
like?
> How do we automate the generation of those reports?
>
> 4) What tools if any such as NDT do we want to arm the end user with for
> testing their own connectivity on demand?
>
> 5) Are there any tools built into networking equipment or passive
monitoring
> tools that we could and are willing to run and could calculate these values
> from live traffic rather than separate measuremnet traffic?
>
> 6) What about measuring and reporting these or other values for QoS
traffic?
>
> Jeremy Powell
>
>
>
> _______________________________________________________________________
> Statement of Confidentiality: The contents of this e-mail message and any
attachments are intended solely for the addressee. The information may also
be confidential and/or legally privileged. This transmission is sent for the
sole purpose of delivery to the intended recipient. If you have received this
transmission in error, any use, reproduction, or dissemination of this
transmission is strictly prohibited. If you are not the intended recipient,
please immediately notify the sender by reply e-mail, send a copy to
postmaster at sbcss.k12.ca.us and delete this message and its attachments, if
any.
>
> E-mail is covered by the Electronic Communications Privacy Act, 18 USC SS
2510-2521 and is legally
> privileged.
> _______________________________________________
> Mtools-report mailing list
> Mtools-report at lists.cenic.org
> http://lists.cenic.org/mailman/listinfo/mtools-report

_______________________________________________________________________
Statement of Confidentiality: The contents of this e-mail message and any attachments are intended solely for the addressee. The information may also be confidential and/or legally privileged. This transmission is sent for the sole purpose of delivery to the intended recipient. If you have received this transmission in error, any use, reproduction, or dissemination of this transmission is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail, send a copy to postmaster at sbcss.k12.ca.us and delete this message and its attachments, if any.

E-mail is covered by the Electronic Communications Privacy Act, 18 USC SS 2510-2521 and is legally 
privileged. 