[Fwd: Re: passive packet measurement]

[Nick Duffield <duffield@research.att.com>]

Mike, thanks for your comments; am forwarding to the
psamp list and will followup there. Nick

-------- Original Message --------
Subject: Re: passive packet measurement
Date: Thu, 31 Jan 2002 19:05:36 -0800
From: Michael MacFaden <mrm@riverstonenet.com>
To: Nick Duffield <duffield@research.att.com>
CC: calato@riverstonenet.com
References: <3C4752BD.D22F8055@research.att.com>

Hi Nick,

Sorry to be so slow in responding. So thanks for the heads up. 

We agree that sampling methods are complementary to current flow
based collection and also that both are pertinent
to ip router vendors. 

I read the draft and had the following comments:

sec 3.1: 

I can the benefit though in terms of adding new experiments to
existing ones without disturbing them, especially given
that the experiments work best when they have run to their
needed time span. Need to consider device reporting capacity 
such that one knows when a new experiment can be created
or not.

sec 3.3: 

I wouldn't characterize TCP as 'reliable' compared
to UDP. IPFIX simply refers to characteristic of being flow 
controlled or not. Reliablity is one of those imprecise 
terms that really depends on what your application does/needs. 
There are applications using UDP which just as reliable as 
TCP that use seq numbers and retransmits. With TCP,
one probably still needs an an application level ack to 
be reliable.

export rate and max delay are hard things to keep bounded 
given the nature of the input and the reliablity of the 
processors and links between the reporter and collector.

sec 3.4: 

Compression comes at a cost, either an onboard
hyphen chip or cpu cycles.

Spacial sampling seems expensive. Having
general purpose devices peering into the entire
contents of a packet is expsensive. Would require 
special gear like coral reef, not common in plain
old routers which are optimized for header access.
  
Generally, there seems to be overlap with the IPFIX
requirements (specifically the contribution from folks 
from inmon) but also the fact that an architecture 
with an exporter and collector is necessary.
But I consider this good news. Maybe at some point the 
the two learn from each other. 

Anyway it will be interesting to see the frameworks developed.

Regards,
Mike MacFaden


On Thu, Jan 17, 2002 at 05:39:57PM -0500, Nick Duffield wrote:
>Michael, Paul,
>
>I'm writing to solicit your feedback on the document "A framework 
>for passive packet measurement" that appeared as an Internet draft
>that appeared last November. It can be downloaded as
>http://www.ietf.org/internet-drafts/draft-duffield-framework-papame-00.txt
>
>The aim is to standardize a set of basic passive packet measurement 
>operations for routers. We position these capabilities as suppliers 
>of measurements to higher level "customers". These customers could
>be on-board applications (e.g. IP traceback, or constructing packet 
>delay statistics) or exported off-board to measurement-based network 
>management applications (e.g. for routine monitoring, or targeted 
>monitoring for intrusion detection). For some applications, the ability 
>to have low latency between packet measurement and reporting will be 
>particularly ueful.
>
>We view passive packet measurement as complementary to flow-based 
>approaches, which offer a compressed summary of packet trains that 
>is particularly useful for reporting network usage.
>
>As a potential user of packet measurements, your feedback would
>invaluable for formulating a good standard. We have set up a public 
>mailing list for discussion, please feel free to direct comments there:
>
>
>          listname : psamp@ops.ietf.org 
>          subscribe: psamp-request@ops.ietf.org 
>          archive  : http://ops.ietf.org/lists/psamp/ 
>
>
>Regards,
>
>Nick Duffield

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