Subject: RE: [IPFIX] Sending export packet

From: "Bhuvaneswari R P - TLS ,Chennai" <[email-masked]>
Date: Thu, 14 Dec 2006 09:53:24 +0530

My question was why don't we go ahead with just one approach. Time based
or packet based ? why do we need to implement both approaches.

-----Original Message-----
From: Paul Aitken [mailto:[email-masked]] 
Sent: Wednesday, December 13, 2006 4:14 PM
To: Bhuvaneswari R P - TLS ,Chennai
Cc: [email-masked]
Subject: Re: [IPFIX] Sending export packet

Bhuvaneswari,

>  Need clarification in below quote from RFC 3954:
> 
>  
> 
> "Two approaches are taken to make sure
> 
> that Templates get refreshed at the Collector:
> 
>     * Every N number of Export Packets.
> 
>     * On a time basis, so every N number of minutes. "
> 
>  
> 
> Any specific reason for having two approaches to send export packet?

This is only needed when you're exporting over an unreliable transport.

You need to refresh the template regularly, else it will time out on the

collector and be expired. Thus the requirement for time based refresh.

However, it's possible that the template was lost in transmission or the

collector was configured with a shorter timeout than the exporter.

So exporting the template every N packets gives you greater assurance 
that your data isn't simply being discarded by the collector because it 
doesn't have the necessary template. This is especially important as 
your export rate grows.

N represents the number of export packets that you care to have 
discarded for this reason - though there's no guarantee, because the 
N'th packet carrying the template could be lost itself.

The worst case would be to send the template in every message - but 
that's terribly inefficient;at that point you would be better to 
consider a reliable export transport.

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

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of 
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and 
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------

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

---

From: "Thomas Dietz" <[email-masked]>
Date: Thu, 14 Dec 2006 09:19:39 +0100

Bhuvaneswari,

As an exporter you just need to implement one of the two approaches. We have
those two approaches because it may be convenient for one expoter to do it
time based an for the other one to do it based on the number of packets. If
you have a rather low volume of flows to export the packet approach is
better. But if you export a high number of flows the time based approach may
be more feasable.

As a generic collector you must be prepared for both. (If you just build a
special collector knowing to receive only flows with one approach you just
need to implement that.)

Best Regards,

Thomas

-- 
Thomas Dietz
Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany

> From: Bhuvaneswari R P - TLS ,Chennai [mailto:[email-masked]] 
> Sent: Thursday, December 14, 2006 5:23 AM
> To: Paul Aitken
> Cc: [email-masked]
> Subject: RE: [IPFIX] Sending export packet
> 
> 
> --------------------------------------------------------------
> ---------------------------------------------------------
> 
> The contents of this e-mail and any attachment(s) are 
> confidential and intended for the named recipient(s) only.
> It shall not attach any liability on the originator or HCL or 
> its affiliates. Any views or opinions presented in 
> this email are solely those of the author and may not 
> necessarily reflect the opinions of HCL or its affiliates.
> Any form of reproduction, dissemination, copying, disclosure, 
> modification, distribution and / or publication of 
> this message without the prior written consent of the author 
> of this e-mail is strictly prohibited. If you have
> received this email in error please delete it and notify the 
> sender immediately. Before opening any mail and 
> --------------------------------------------------------------
> ---------------------------------------------------------
>

---

From: "Thomas Dietz" <[email-masked]>
Date: Thu, 14 Dec 2006 09:19:39 +0100

Bhuvaneswari,

Best Regards,

Thomas

---

From: Paul Aitken <[email-masked]>
Date: Thu, 14 Dec 2006 10:53:38 +0000

Thomas,

> If you have a rather low volume of flows to export the packet
> approach is better.

No. Your export volume could be too low to reach the threshold for
sending the next template update before the collector expires the template.

> But if you export a high number of flows the time based approach may 
> be more feasable.

No. You could export 10^n flows without the collector having a template
to decode them, so they would all be discarded.

> As a generic collector you must be prepared for both.

Agreed.

> (If you just build a special collector knowing to receive only flows
> with one approach you just need to implement that.)

If the job's worth doing, it's worth doing right. It's hardly very
difficult to implement both algorithms!

---

From: Paul Aitken <[email-masked]>
Date: Thu, 14 Dec 2006 10:53:38 +0000

Thomas,

Agreed.

---

From: Andrew Johnson <[email-masked]>
Date: Thu, 14 Dec 2006 18:16:23 +0000

> better. But if you export a high number of flows the time based approach may

I'm pretty sure time-based sending is a definite MUST for UDP.  A Collector
should consider a Template that is not sent within a suitable lifetime as
removed.

I've always viewed the packet-based sending as an extra safety-net to ensure
that you can limit the amount of lost data from a dropped template when
sending at high packet rates.

Andrew

> ------------------------------------------------------------------------
>

---

From: Andrew Johnson <[email-masked]>
Date: Thu, 14 Dec 2006 18:16:23 +0000

Andrew

---

From: Lutz Mark <[email-masked]>
Date: Thu, 14 Dec 2006 19:28:44 +0100

> sending at high packet rates.

I agree.

Should we clarify this in the implementation guidelines?

Regards,
Lutz

---

From: Lutz Mark <[email-masked]>
Date: Thu, 14 Dec 2006 19:28:44 +0100

I agree.

Regards,
Lutz

---

From: Brian Trammell <[email-masked]>
Date: Thu, 14 Dec 2006 13:33:02 -0500

Yep.. the rationale behind the two timeout regimes needs to be
explained, and the guidelines seem the place to do it.

Yet again, it should also be noted that since the UDP Transport Session
is  bounded by its template retransmit timeouts, UDP Transport Sessions
may expire if too many packets go by without a template retransmit.

#include <bht/rants/i_dont_like_ipfix_over_udp.txt>

Regards,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Thu, 14 Dec 2006 13:33:02 -0500

Regards,

Brian