[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: passive packet measurement
If you think that it will be useful,
From: Nick Duffield [mailto:firstname.lastname@example.org]
Sent: Thursday, January 24, 2002 1:59 PM
Subject: Re: passive packet measurement
Can you send your comments to the psamp
mailing list email@example.com also?
Carter Bullard wrote:
> Hey Nick,
> Here are my comments, not in any particular order.
> If you would like to talk about them, don't hesitate to
> give me a call. I do hope that you find them useful.
> Carter Bullard
> QoSient, LLC
> 300 E. 56th Street, Suite 18K
> New York, New York 10022
> Phone +1 212 588-9133
> Fax +1 212 588-9134
> Comments on draft-duffield-framework-papame-00
> "A Framework for Passive Packet Measurement"
> I don't believe that you made the case for packet
> sampling. While it maybe useful, packet selection
> techniques that are purely filter based are also
> perfectly adequate for controlling the load that a
> packet monitor may encounter. A facility that
> measures and reports only on ICMP packets is more
> than legitimate, its actually useful, and sampling
> isn't appropriate in this case.
> Your sampling types and descriptors are a bit primitive.
> You could easily beef that up by having some real
> statistical sampling methods described.
> A framework for packet measurement should handle
> full wire-line measurement as well as packet selection
> techniques. I don't have a problem with having a
> sampling technique of "all packets".
> It seems that your describing an implementation, not a
> framework. No sense in calling it a framework unless you
> plan on really building a framework. If you're building
> a framework, then your section 3. Measurement Functionality
> shouldn't read like an implementation, but rather a design.
> So, I should be able to do filtering any way I want, it
> shouldn't have to be tied into the Hashing function. Actually
> if I'm really thinking about hardware and performance,
> I'm going to want to Filter before I Hash. Possibly
> there is an advantage to doing some Filtering in conjunction
> with the Hashing function, but it can't be the only way
> to do filtering. I believe that a framework should identify
> the issues, and suggest a possible implementation, as an
> You shouldn't allow state variables to be supplied to the
> record after any period of delay, as there is no assurance that
> the variables will be applicable. If the value isn't the
> actual value that the network element used to dispatch/process/
> whatever the packet, then you risk jeopardizing the credibility
> of the entire mechanism.
> Other than that, it seems like a good start.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.