RE: FW: Comments on sFlow RFC 3176

From: Ayyasamy, Senthilkumar (UMKC-Student) (saq66@umkc.edu)
Date: 04/27/02

  • Next message: Peter Phaal: "Using sFlow to analyze TCP connection statistics"

            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