Subject: Re: [IPFIX] ipfix-configuration-02

From: Benoit Claise <[email-masked]>
Date: Tue, 20 Nov 2007 14:27:53 +0100

Dear Kobayashi-san, Gerhard,
>
>>> - 5.4 CacheParameters Class
>>> If we select the "immediate" type, the IPFIX datagram might have only
>>> one flow records. Generally, the load of router depends on the volume of
>>> IPFIX packets. Preferably, it is better that IPFIX datagram has multiple
>>> flow records. To mitigate it, I hope that this class has the maximum
>>> timer until it exports them.
>>> Even if we select "immediate", it can wait until time out, or the flow
>>> records are filled in the IPFIX packet.
>>>       
>> Good point. In former versions (-00,-01), I had introduced two Exporting
>> Process parameters:
>>
>>        <ipfixPacketRestrictions>
>>          <maxPacketSize>1500</maxPacketSize>
>>          <maxExportDelay unit="msec">500</maxExportDelay>
>>        </ipfixPacketRestrictions>
>>
>> The first specifies the maximum IPFIX message size, which can be useful
>> to avoid fragmentation in the case of UDP. Yet, as devices can query the
>> MTU autonomously, we omitted this parameter in -02.
>>
>> The second parameter was to specify a maximum export delay which allows
>> the Exporting Process to wait for more records if the IPFIX message is
>> not yet filled. I think this corresponds to the timer you are referring to.
>> We omitted this parameter because Flexible Netflow does not allow to
>> configure it. In our implementation (Vermont), we do have both of these
>> parameters, and we would extend the configuration data model with
>> device-specific parameters in order to configure them.
>>
>> Yet, if more people think that we need something like maxExportDelay, we
>> can add such a parameter in the standard configuration data model.
>>
>>     
>
> I agree 2 parameters, maxPacketSize and maxExportDelay.
>   
I'm wondering if this is such as good idea to add those parameters.
The propability to need maxExportDelay in real live is very low. I've
seen the need _in my lab_ when we test a single ping, and there is a
single flow to be exported: not quite enough to fill in the export
packet. But I've never seen the need in real live. However, if such a
timer is implemented in our boxes, it's not configurable.
Btw, for the immediate cache type, the goal is send a packet as far as
possible. A typical case is for security (note that immediate cache type
should only be used in seldom situations). So having a maximum timer
before the export goes a little bit against the goal.
In the posted draft, here is what we wrote:

   o  Request for additional parameters concerning the composition of
      IPFIX messages at the exporter, e.g. how long may the exporter
      wait until an expired record is exported?  Waiting may be useful
      in order to fill up IPFIX messages.
      We (the authors) decided not to add such parameters for the
      following reasons: 1) the composition of IPFIX messages has not
      been described as configurable or managable in any other IPFIX
      document, and 2) today's configuration possibilities depend very
      much on the device or manufacturer.  We propose to use device or
      manufacturer-dependent extensions of the configuration data model.

Note that we missed the deadline for the draft submission by 20
minutes... :(

Regards, Benoit.
_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: Benoit Claise <[email-masked]>
Date: Tue, 20 Nov 2007 14:27:53 +0100

Regards, Benoit.

---

From: kobayashi atsushi <[email-masked]>
Date: Wed, 21 Nov 2007 16:03:38 +0900

Dear Benoit and Gerhard,

Please see in-line.

On Tue, 20 Nov 2007 14:27:53 +0100

> timer is implemented in our boxes, it's not configurable.

I see what you mention. But I can image "maxExportDelay" is 0 by the
term of "immediate". It seems to export observed packet immediately. 
But, If "maxExportDelay" is 0, I am afraid that it overloads up Exporter.
At least, Exporter should have the timer to export efficiently, even if
this is not configurable parameter.

> In the posted draft, here is what we wrote:

This goal seems to be too little. I would like to use "immediate" type
by measuring the packets loss. 
For example, by filtering streaming IPTV packet, and exporting them
immediately, we can trace the sequence number of RTP header. Definitely,
it can be used as trouble shooting tool, when customer asks the network
condition. It might become powerful tool. It is not seldom situation.

To achieve the above solution, how to configure the IPFIX parameters is
important.

>       manufacturer-dependent extensions of the configuration data model.

I think above description is probably needed in the PSAMP protocol draft.

Best Regards,
Atsushi KOBAYASHI

> Note that we missed the deadline for the draft submission by 20

--- 
Atsushi KOBAYASHI  <[email-masked]>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637

---

From: kobayashi atsushi <[email-masked]>
Date: Wed, 21 Nov 2007 16:03:38 +0900

Dear Benoit and Gerhard,

Please see in-line.

Best Regards,
Atsushi KOBAYASHI

---

---

From: Gerhard Muenz <[email-masked]>
Date: Wed, 21 Nov 2007 11:06:58 +0100

Dear Kobayashi,

> I think above description is probably needed in the PSAMP protocol draft.

My understanding of the IPFIX packet composition at the Exporting
Process is the following:

The output of the Metering Process is a stream of records. These records
can be PSAMP or IPFIX records. For the Exporting Process, this
difference does not matter.

The records enter some kind of export buffer in the Exporting Process.
The Exporting Process asynchronously polls the buffer and exports the
records in the most efficient way, i.e it tries to put as many records
as possible in one packet, eventually applies reducing redundancy
mechanisms etc.

As long as the export buffer does not "run out of records", the
Exporting Process will continuously do its job, and there is no need to
worry about small IPFIX packets.

Yet, at some point, the Exporting Process might manage to empty the
export buffer. After, it is in idle mode waiting for new records from
the Metering Process. Assumed that the output of the Metering Process
occurs rather in a bursty way, i.e. more than one record are usually
written into the export buffer at once, the Exporting Process will
resume to operate as described before. Again no worry about small packets.

The only situation where we have to worry about small packets is when a
single record is written into the empty export buffer and after this
there is long silence. This corresponds to Benoit's example. So, what do
you expect from the Exporting Process?

I would say: Wait a very small moment and then export the record. This
very small moment does not have to be configurable, it can be a timer
with constant timeout, and this timeout can be implementation-specific.

What I also want to point out: The discussed problem is independent from
the "immediate" cache type. It may also occur with any other cache type
(see Benoit's example).

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

---

From: Gerhard Muenz <[email-masked]>
Date: Wed, 21 Nov 2007 11:06:58 +0100

Dear Kobayashi,

Regards,
Gerhard

---

From: kobayashi atsushi <[email-masked]>
Date: Wed, 21 Nov 2007 20:30:08 +0900

Dear Gerhard,

I agree your opinion.

On Wed, 21 Nov 2007 11:06:58 +0100

> with constant timeout, and this timeout can be implementation-specific.
Yes.

What I want to say is that it might be problems if this timer is 0.
In this case, exporting process continues to export short IPFIX packets
including one Flow Record. I imaged above situation from "immediate".
Whether implementation-specific, I would like Exporter to have such short
moment timer.

> the "immediate" cache type. It may also occur with any other cache type

Yes.

Surely, it is independent from cache type. 
I thought that the effect of timer 0 becomes larger in "immediate" case,
because number of Flow Records is larger.

It is not necessary that the timer is configurable parameter.

BTW, I can't find "Benoit's example". 

Regards,
Atsushi KOBAYASHI

---

---

From: kobayashi atsushi <[email-masked]>
Date: Wed, 21 Nov 2007 20:30:08 +0900

Dear Gerhard,

I agree your opinion.

Yes.

Yes.

Regards,
Atsushi KOBAYASHI

---

---

From: Gerhard Muenz <[email-masked]>
Date: Wed, 21 Nov 2007 12:46:48 +0100

Dear Kobayashi,

> BTW, I can't find "Benoit's example".

Benoit wrote:
"I've seen the need in my lab when we test a single ping, and there is a
single flow to be exported: not quite enough to fill in the export packet."

As I understand, the situation was as follows: A single ICMP packet
caused a single record, which was not exported until more records were
finally available to fill the packet.
Now, a timer prevents such blocking of the exporter.

Regards,
Gerhard

---

From: Gerhard Muenz <[email-masked]>
Date: Wed, 21 Nov 2007 12:46:48 +0100

Dear Kobayashi,

Benoit wrote:

Regards,
Gerhard

---

From: Paul Aitken <[email-masked]>
Date: Wed, 21 Nov 2007 15:23:12 +0000

Gerhard,

> The records enter some kind of export buffer in the Exporting Process.

Possibly, though not necessarily. That's an implementation detail.

> as possible in one packet, eventually applies reducing redundancy

It might not. A simple device may export one flow per packet. It's not 
very efficient, though there's nothing against it in IPFIX.

> resume to operate as described before. Again no worry about small packets.

I disagree. It's quite possible to imagine the Metering Process filling 
the export buffer, writing one entry in the queue then going off for a 
moment to discover whether there are further entries to enqueue. So 
while it appears almost continuous, there is a small gap between queued 
entries. Make it as infinitely short as you like; there's a small gap.

Meanwhile, the Exporting Process wakens during that gap and discovers 
just one record is enqueued.

With perfect sync of the MP and EP (eg, due to process scheduling) what 
you'd get is an export stream consisting of single Data Records per packet.

So the scheme you describe inherently relies upon the Exporting Process 
waiting a small amount of time to see whether there's any further data 
to be exported - which means that data isn't being exported from the box 
as absolutely fast as possible. Clearly there's a trade-off between 
speed and efficiency.

> with constant timeout, and this timeout can be implementation-specific.

Indeed, it seems that such a timer would be better understood and 
designed by the system implementor than by the user.

> the "immediate" cache type. It may also occur with any other cache type

Agreed.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

---

From: Paul Aitken <[email-masked]>
Date: Wed, 21 Nov 2007 15:23:12 +0000

Gerhard,

Agreed.