Hi Sonia ,
I really thought of raising some of these points .I am pretty well clarified by your answers.
But,I am still having some doubts regarding this subject
Netflow employs source based aggregation .Psamp essentially discusses packtet
based sampling.The discussion you had in IPFIX was really helpful in clarifying
some of my doubts.My question is *will a combination of source based aggregation
and packet sampling is useful for some applications or prove disadvantage for
some applications *
The reason for the above question is that ,I now formed a effective router plugin
framework with counters and all features.I want to test both sampling as in sflow(i can
use the code pointed out by you) and source based aggregation too.I like to do this
as a performance study with some effects in the measurement points in high speed
backbones like internet2.
Actually,I am pretty interested in time series modelling and traffic measurements in
general.But,being a graduate student and working for a professor in a different area
of research (analytical modeling for self-similar traffic) gives me little time to spare .
I really thought i can do something constructively and put up in the psamp mailing
list for discussion.I have some how come up with the framework but have to add all
the plugins .I was little facinated by the BSD filter concept too.why cant smapling
by added at machine instruction level to the existing filter code in BSD .
I am waiting for summer to continue this work.
Thanks in advance ,
-Senthil
-----Original Message-----
From: Sonia Panchen [mailto:sonia_panchen@inmon.com]
Sent: Thu 4/25/2002 9:50 PM
To: sflow@sflow.org
Cc:
Subject: [sFlow] FW: Comments on sFlow RFC 3176
Tanja Zseby from the Fraunhofer Institute FOKUS/Global Networking made some
good comments about sFlow as described in RFC 3176 which may be of broader
interest:
-----Original Message-----
From: Sonia Panchen [mailto:sonia_panchen@inmon.com]
Sent: Tuesday, April 23, 2002 1:17 PM
To: Tanja Zseby
Cc: quittek@ccrle.nec.de; zander@fokus.gmd.de; carle@fokus.gmd.de
Subject: RE: Survey of traffic flow measurements at saint2002
Tanja,
Thank you very much for taking the time to reply. Your comments are
valuable, and we will include the feedback in the next documents.
I have made some comments in-line below.
Would it be OK to post this to the discussion group on www.sflow.org? I
think some of this discussion may be useful to others too.
Sonia
> -----Original Message-----
> From: Tanja Zseby [mailto:zseby@fokus.gmd.de]
> Sent: Tuesday, April 23, 2002 8:56 AM
> To: Sonia Panchen
> Cc: quittek@ccrle.nec.de; zander@fokus.gmd.de; carle@fokus.gmd.de
> Subject: Re: Survey of traffic flow measurements at saint2002
>
>
> Hi Sonia,
>
> I have some comments on RFC3176:
>
> - formula (1): I always associated with the term "sampling rate" the
> sampling probability p (e.g. 1/10) that means sampled_packets to
> total_packets. I think in the sFlowBilling paper you use it in th same
> way. But in RFC 3176 it is total_packets/sampled_packets. This I found
> confusing.
>
This is a good point. We at least should be consistent!
> - section 2.1.2: it is mentioned that a variation of +/- 10% of the mean
> value is sufficient. But it is not mentioned for what it is sufficient.
> I assume it is meant that you get a sufficiently accuracte prediction of
> the error ? Or do you refer to certain apllications ?
>
We found through simulation, experiments, and statistical analysis that the
results we obtained from processing the samples (ie scaling as described in
the sFlowBilling paper) did not vary significantly provided that the random
number generation resulted in values within +/-10% of the mean.
> - section 2.2.: was hard to understand for me. It was not clear to me
> what exactly you sample here and what parameter you want to estimate. I
> understand that you are polling the IF counters regularily. Does the
> sampling process select which counters you read or at which time
> intervals ?
>
I see your point. The "sampling" of network interface statistics is really
local polling or time-based sampling of the interface counters.
This is probably more understandable when read in conjunction with the
specifics of the MIB and datagram. For example the MIB
(sFlowCounterSamplingInterval) allows the polling interval to be set and the
datagram (if_counters) defines the counters which are read.
> - 3.2 (sflow MIB) sampling rate definition: see comment above.
> Furthermore the sentence "a sampling rate of 0 disables sampling" could
> be confusing. Disabling sampling sounds to me like capturing all packets
> but I guess it is meant that no packet is selected for the
> sample, correct ?
>
This is also a good point, and I could see how it might be confusing.
But you are correct. Disabling sampling was meant to mean no packets are
selected.
> Hope this was some constructive input.
>
This was very constructive - thank you. It is always good to get a different
perspective.
The RFC was written in the form of an implementation guide or ERS/interface
specification. I think you point out the value of a more narrative overview
too.
> Regards
> Tanja
> --
> Dipl.-Ing. Tanja Zseby
> FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de
> Kaiserin-Augusta-Allee 31 Phone:
> +49-30-3463-7153
> D-10589 Berlin, Germany Fax:
> +49-30-3463-8153
> ------------------------------------------------------------------
> --------------------
> "Living on earth is expensive but it includes a free trip around
> the sun." (Anonymous)
> ------------------------------------------------------------------
This archive was generated by hypermail 2b29 : 04/27/02 EDT