Subject: [PSAMP] completing the PSAMP protocol

From: "Juergen Quittek" <[email-masked]>
Date: Fri, 10 Nov 2006 03:46:36 +0100

Dear all,

I am very happy that the IPFIX protocol has passed IESG evaluation and will
enter the RFC editor queue.  Now we can have the PSAMP protocol following 
quickly.

I think that draft-ietf-psamp-protocol-07.txt is in very good shape.
There is only one issue I would like to discuss before submitting it
to our AD with a request for publication.  Please send a message to
this list if yo see further issues.

The issue is distinguishing PSAMP and IPFIX reports.

An IPFIX flow report contains information about one or more packets
while a PSAMP report contains information about exactly one packet.
There is no problem with this if the report contains a packet counter.
But if not, it might be unclear if, for example, an octet counter 
indicates the number of octets of a flow or the number of octets of
a single packet.  Therefore, I would like to have a means to distinguish
packet reports from flow reports.

Does anyone have a good suggestion for solving this problem?

Or does anyone think that is not a problem?

Input is highly appreciated, because it will help completing
the PSAMP protocol soon.

Thanks,

    Juergen

_______________________________________________
PSAMP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/psamp

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 10 Nov 2006 09:47:48 +0100

Dear Juergen,

I would say it is not a problem since a flow template/record usually
contains a packet counter.

However, we could recommend to export the packet counter within flow
records if PSAMP and IPFIX data are exported by the same Exporter (or
from the same Observation Domain).

A related question is if it is allowed having packet counter and payload
in the same record. If yes, how do you interprete the payload? Is it the
payload of the first packet in the flow?
Or is this issue already clarified in the PSAMP specifications?

Regards,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen
Sand 13 (Room B309), D-72076 Tuebingen, Germany
Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220
E-mail: [email-masked]
WWW:    http://net.informatik.uni-tuebingen.de/~muenz
_______________________________________________
PSAMP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/psamp

---

From: Juergen Quittek <[email-masked]>
Date: Sat, 11 Nov 2006 11:40:17 +0100

Gerhard,

Let me add further clarification.

I am not necessarily requesting that a single
flow record contains means for distinguishing
between a flow record and a packet record.
Such information could also be communicated
in the template or in an option record.

However, there is a semantic difference between
a packet record and a flow record. Even if a packet
record and a flow record are identical for every bit
they contain, the contained information is different.
Therefore, I want a collector to be able to
distinguish between them.

This is certainly not a problem for records
containing a packet counter. But IPFIX allows flow
records that do not have packet counters.  In such
a case the collector needs further information
about the received data.

Since IPFIX is the base protocol, I would see a flow
record as the default case that does not need any
specific tag.  But for packet records I would like
to see a means that clearly identifies them as such.

Thanks,

    Juergen

---

From: Gerhard Muenz <[email-masked]>
Date: Sun, 12 Nov 2006 11:35:26 +0100

Juergen,

Let me first comment the suggestion in your previous mail:

> What about sending a packet counter with value 1 in an option template
> for packet reports?

The problem remains and becomes even worse if you use a flow counter for
packet records: If the value is 1, it still might be a normal flow record.

The only solution would be to recommend the following:
* always use flow counters for flow records, and
* never use flow counters for packet records.

If you want a stricter distinction between flow records and packet
records, you might like this idea:
We had a similar problem when specifying how to export records of
filtered flow aggregates in draft-dressler-ipfix-aggregation. We solved
this by using a new template set (Data Template) which is announced with
Set ID=4.
This could also be a solution to distinguish between flow records and
packet records: Use another Set ID (e.g. 5) to define a PSAMP Template
Set. The format of the set would be the same as for normal (flow)
Template Sets  (Set ID=2), but the collector would know that the data
originates from a PSAMP probe.

Regards,
Gerhard

---

From: Andrew Johnson <[email-masked]>
Date: Mon, 13 Nov 2006 05:09:15 +0000

Hi all

I'm not convinced that the application is needed in-band.  IPFIX is
a transportation protocol, the application using it should know what
it's doing.

OTOH, general purpose collectors seems a reasonable idea.  So if an
in-band way of knowing the application is desirable, then I don't
think using packet counters is explicit enough and new Set IDs are
going way too far.  At that point PSAMP won't even be using IPFIX
as defined in IPFIX PROTO.

Why can't we just define a new application I.E.?  I agree that the
default application is going to be Flow Export, but IPFIX will have
a number of application relatively soon.  With a new I.E. we can
send it per data record or in an option scoped to the template.  It
requires no protocol changes, is explicit and can be used flexibly.

regards

Andrew

Gerhard Muenz wrote:
> ------------------------------------------------------------------------
>

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 13 Nov 2006 17:42:49 +0100

Hi all,

> a transportation protocol, the application using it should know what

To be precise, it's an IP flow information export protocol :-)
Here, we are using it for packet information export.

> as defined in IPFIX PROTO.

The point is that it does not cost us much now to avoid confusion.
I do not feel well with opening the possibility that two identical
streams of reports have different meanings without the collector
being able to distinguish.  This does not imply that we need to change
the protocol.  We may, but IPFIX is rich enough to offer us several
ways of giving the collector additional information on the records.

> requires no protocol changes, is explicit and can be used flexibly.

This would be a way to do it.  Wouldn't you still call this in-band?

Thanks,

    Juergen

---

From: Brian Trammell <[email-masked]>
Date: Mon, 13 Nov 2006 11:52:21 -0500

Andrew,

I agree fully... the use of such an information element shouldn't be  
_required_, because in the general case I would suspect that the  
application is implicit in the identity and configuration of the  
Collecting and Exporting Processes.

For our own applications, we've generally used the presence of  
certain IEs (packet count for flows, flow count for aggregates) to  
define the application as mentioned elsewhere in this thread.  
However, in those cases in which it isn't possible to divine the  
application from out-of-band configuration or the template, it's  
quite useful to be able to represent the record type in-band.

(Note also, this is very much parallel to the problem of representing  
direction selection method for biflows.)

Regards,

Brian

---

From: Andrew Johnson <[email-masked]>
Date: Tue, 14 Nov 2006 09:25:29 +0000

> Here, we are using it for packet information export.

I don't think the usage of IPFIX should be limited by its name.  It's
a very flexible format and I expect we'll see a number of applications
quite soon.

> ways of giving the collector additional information on the records.

Obviously you feel strongly that a way of explicitly reporting the
application is desirable, so by all means let us define how to do so.
I agree that we do not have to change or extend the IPFIX protocol to
do so, which is why I am against adding new Set IDs as suggested by
Gerhard.

> This would be a way to do it.  Wouldn't you still call this in-band?

Of course.  I'm not against in-band communication if it is desirable,
and although I don't think it is required by default, I can see why
an in-band communication could be useful.

A new I.E. is a very small addition to PSAMP.  It can explicitly
differentiate between single-packet flow records and PSAMP records,
and it can be extended to include future applications.  I would
suggest we have an IANA controlled 32-bit application ID that would
usually be RLE'ed down to 1 octet:
  0 - Unknown application
  1 - Flow Monitoring
  2 - PSAMP

Regards,

Andrew

---

From: Andrew Johnson <[email-masked]>
Date: Tue, 14 Nov 2006 11:53:32 +0000

> Collecting and Exporting Processes.

Absolutely.  I presume you second the motion of a new IE for the
application.  All in favour say "Aye!" :-)

> For our own applications, we've generally used the presence of certain 
> IEs (packet count for flows, flow count for aggregates) to define the 
> application as mentioned elsewhere in this thread. However, in those 
> cases in which it isn't possible to divine the application from 
> out-of-band configuration or the template, it's quite useful to be able 
> to represent the record type in-band.

OK, so you agree with Jeurgen that we need this.

> direction selection method for biflows.)

Why?  Because it's usually available out-of-band but sometimes it would
be useful to be explicitly in-band?  How to solve this... I know, use a
new I.E. :-)

Cheers

Andrew

>>>>> --Dipl.-Ing. Gerhard Münz