FW: passive packet measurement

["Carter Bullard" <carter@qosient.com>]

Hey Nick,
   If you think that it will be useful,
no problem!

Carter


-----Original Message-----
From: Nick Duffield [mailto:duffield@research.att.com] 
Sent: Thursday, January 24, 2002 1:59 PM
To: carter@qosient.com
Subject: Re: passive packet measurement


Carter,

Can you send your comments to the psamp 
mailing list psamp@ops.ietf.org also?

Thanks,

Nick

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
> 
> Carter Bullard
> QoSient, LLC
> 300 E. 56th Street, Suite 18K
> New York, New York  10022
> 
> carter@qosient.com
> Phone +1 212 588-9133
> Fax   +1 212 588-9134
> http://qosient.com
> 
> 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
> example.
> 
> 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.
> 
> Carter





to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.