Subject: Re: [ipfix] Per-packet record proposal (pktId)

From: Changhoon Kim <[email-masked]>
Date: Tue, 08 Jul 2003 17:00:07 +0900

Hello Tanja,

I compared your draft ("FOKUS") with ours ("ETRI") and summarized the common
points and the differences. Some open questions to ipfixers which, I 
reckon, may be
raised during our presentation at the Vienna meeting are also included.
(Our draft can be found at 
http://www.ietf.org/internet-drafts/draft-kim-ipfix-ppr-00.txt,
 but the one we advertised on June 26 as an attachment of a mail to 
ipfix was the most
 updated version.)

1. Common Points

* Objective
   - Incorporating per-packet information export into the existing IPFIX 
proposals.
[Q]: Is there a common agreement on including ppr export to ipfix's scope?
       I'd like to listen to the voices of the group members on this issue.

* Necessity and Applicability
   - Highly various; including QoS monitoring, usage-based accounting, 
traffic profiling,
     and application recognition.

* Data Export Extension
   - At least two different forms of FlowSet are required; one for flow 
records and
     the other for packet records. Defining new FlowSets can be easily 
accomplished
     using template records.  

2. Differences

* Information Model
    - ETRI includes basic information model elements mostly based on 
IPv4/TCP
      headers and packet payload. It doesn't include a global 
identification field for
     a packet, while FOKUS does.
[Q]: Given that all the required values for generating global id is 
provided,
       what about computing packets' global id in the collecting process?
       We found that the ipfix requirements and information model draft 
also didn't
       mention to exporting global flow ids.

* Configuration Extension
    - ETRI introduces a selection criteria for enabling/disabling 
per-packet record generation
      with an emphasis on optional packet payload investigation.

* Data Export
    - FOKUS proposes to use the Flow Index to associate the packet 
records to
      the corresponding  flow records. ETRI's approach is to associate 
the two
      records on the basis of the order of FlowSets; the FlowSet conveying
      flow information must be disposed right ahead of the FlowSet conveying
      per-packet records. The FlowSet for flow records may be of the 
same form
      as the existing FlowSet or may be newly defined so that the new 
FlowSet can
      contain minimal information -- e.g. a unique flow index.
    - According to FOKUS, a FlowSet for Packet Properties can contain 
the information
      of packets which belong to multiple flows. In ETRI's proposal, on 
the other hand,
      a FlowSet for per-packet records contains the information of 
packets of a single flow. 
    - ETRI mentions to packet record export intervals.
[Q]: According to FOKUS, does every pkt record need to contain its 
corresponding
       flow index? If so, this may incur redundancy, and if not, it may 
also require a separate
       form of FlowSet to convey the flow id.

We would deeply appreciate active answers or rigorous comments for the 
above questions
and analysis result.

Best regards,

Chang

Tanja Zseby wrote:

> Hi,
>
> we support the idea to integrate a field for a packet ID for multiunit 
> QoS measurements.
> Maybe you can have a look at a paper that we presented a few month ago 
> on how to use IPFIX/netflow9 for passive one-way delay measurements:
> http://www.ist-intermon.org/workshop/papers/03_03_powd-netflow9.pdf
> We also started a separate draft on this (see attachment, not yet 
> submitted) for exporting pktIDs and per packet timestamps with IPFIX .
>
> Regards
> Tanja
>

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: "David Diep" <[email-masked]>
Date: Wed, 9 Jul 2003 14:29:26 +0900

Dear Guido and Chang,

Just as a precision, I think that the FlowIDs (i.e. flow index value)
just need to be unique within a NetFlow instance on a particular device
at a given time because when a collector receives a NetFlow packet it
can use the source IP address and the SourceID parameter of the NetFlow
packet header to avoid any mistake due to FlowIDs collision. So FlowIDs
do not need to be globally unique. 

Concerning the packet IDs I think they just need to be unique within a
flow under observation. The packet ID is not globally unique.

Best Regards,

David Diep

-----Original Message-----
From: Guido Pohl [mailto:[email-masked]] 
Sent: Wednesday, July 09, 2003 2:06 AM
To: Changhoon Kim
Cc: Tanja Zseby; David Diep; [email-masked]; [email-masked];
Guido Pohl; Lutz Mark; Carsten Schmoll
Subject: [ipfix] Per-packet record proposal (pktId)

Dear Chang,

concerning your mail and questions please find our comments inline ...
I will answer the questions with the hope the answers are in sync with
the other people of the team ;-)

  > I'd like to listen to the voices of the group members on this issue.

   Assuming that ppr is short for per-packet record, I've found the
following in the requirements draft
   draft-ietf-ipfix-reqs-10.txt:
   Please note that not all requirements for QoS monitoring are covered
   by the IPFIX requirements specified in the following sections. The
   IPFIX requirements are targeted at per flow information including
   summaries of per-packet properties for packets within a flow, but not
   per-packet information itself. For example jitter measurement
   requires timestamping each packet and reporting of all timestamps of
   a flow, but the IPFIX requirements only cover timestamps of first and
   last packet of a flow.
   So it seems that per-packet export has "never" taken into
consideration ...

provided,
also didn't
  > mention to exporting global flow ids.

  Behind the idea of generating a packet id for packets stands pure
parsimony.
   So if the information exported per packet is rather sparse i.e. not
the complete
   header and parts of the payload then one can save resources in terms
of network
   bandwidth ...
  Of course, if all the information are to be exported anyway we could
calculate
   identifiers after collecting the per-packet records.
  I think, that FlowIDs do not need to be globally unique, instead they
are in conjuncion
   with the information who exports the data. (But yes this is not
clearly stated in the draft
   (that is to come).

corresponding
also require a separate
  > form of FlowSet to convey the flow id.

  Yes. We intended to include the flow index.
   A second way would be to relate somehow whole packet information sets
(with same flow
   properties) to templates and then relate templates to specific flows
- I guess.
   We should think about the impact of the solutions more closely.

>
  > We would deeply appreciate active answers or rigorous comments for
the above questions
  > and analysis result.
  Thanks for your comments so far. Hope that I could clarify the
question - please feel free to contact me again if not.
   Kind regards, Guido
  -- _ Guido Pohl                      /\    Phone  : +49 30 3463 7164
_
_ Fraunhofer FOKUS -=CC MeTeoR=-/^ \   FAX    :             8164
_
_ Kaiserin-Augusta-Allee 31     //_\_\  E-Mail :
[email-masked] _
_ 10589 Berlin, Germany        /____\
_