Subject: Re: [tsv-dir] Re: Transport Directorate review of draft-ietf-ipfix-implementation-guidelines-06.txt

From: Lars Eggert <[email-masked]>
Date: Thu, 6 Sep 2007 12:39:42 +0300

On 2007-9-6, at 12:01, ext Elisa Boschi wrote:
>> To be specific, how would an application using
>> IPFIX over UDP obtain the packet loss information needed to implement
>> TFRC as recommended in Section 3.1.1 of the UDP guidelines draft?
>> The IPFIX implementation guidelines draft says:
>>    The Collecting Process SHOULD use the Sequence Number in the IPFIX
>>    Message header to determine whether any messages are lost.
>> but I don't see how the Exporting Process can learn this information
>> in order to adjust its sending rate using TFRC (did I miss  
>> something?).
>> A discussion of how to implement TFRC or what to do on a dedicated
>> network when TFRC is not implemented would be useful.  The fact that
>> there was a working NetFlow implementation might be helpful in
>> configuring IPFIX to not congest the dedicated network.
>
> Right, so I've asked Paul Aitken from Cisco about it and this is  
> his answer:
>
> ---
>
> We don't take any active measures not to congest. Rather, we expect  
> the
> user to design their network well.
>
> We believe netflow export consumes 2-5% of the bandwidth of the  
> sampled
> traffic. So export over a dedicated 100M link should be able to  
> support
> netflow on 20-50 x 100M interfaces.
>
> IPFIX will be very similar.
>
> Looking at draft-ietf-tsvwg-udp-guidelines-02, I see TFRC recommended
> for "Bulk Transfer Applications" (section 3.1.1).
>
> However, I think that netflow and IPFIX export fall into the "Low
> Data-Volume Applications" category (section 3.1.2) which says:

I don't see IPFIX falling into this category. IPFIX will send many  
packets to a destination. (And even if IPFIX fell into this category,  
it'd need to implement congestion control mechanisms for low-datarate  
applications, which the draft also gives guidelines for.)

>     When applications that exchange only a small number of messages  
> with
>     a destination at any time implement TFRC or one of the other
>     congestion control schemes in Section 3.1.1, the network sees  
> little
>     benefit, because those mechanisms perform congestion control in  
> a way
>     that is only effective for longer transmissions.
>
> So I don't think discussion of how to implement TFRC for IPFIX/UDP is
> relevant.
>
> ---
>
> I agree with him on this.
>
> Would you be fine with this motivation? Maybe we could add a  
> reference to section 3.1.2 of the UDP guidelines in the text?

Lars

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

---

From: Elisa Boschi <[email-masked]>
Date: Thu, 06 Sep 2007 11:01:54 +0200

David,

> 
> We're getting close, but I think some more work on UDP guidelines
> is still appropriate.  As the existence of the UDP guidelines draft
> indicates, this is a topic of current interest in the Transport Area.
> 

see inline

>>>>  > Section 6.2: UDP
>>>>  >
>>>>  > [2] I don't see any discussion of congestion control in here.
>>>>  > Something needs to be done to avoid a high rate IPFIX protocol
>>>>  > session over UDP worsening a congestion situation because not
>>>>  > only is the IPFIX flow non-responsive to congestion, but
>>>>  > congested conditions may increase the volume of IPFIX data
>>>>  > to be reported.  At the very least, this draft should repeat
>>>>  > and reinforce the discussion in Section 10.3.1 of
>>>>  > draft-ietf-ipfix-protocol-24.txt, which says that UDP should
>>>>  > not be used over congestion sensitive network paths - I'm not
>>>>  > thrilled about that approach, but the ipfix-protocol draft
>>>>  > is already in the RFC Editor Queue.  A general recommendation
>>>>  > against UDP when TCP or SCTP is possible may be appropriate,
>>>>  > and the first item in Section 10.1 is related to this concern,
>>>>  > as it requires availability of a congestion-controlled protocol.
>>>>
>>>> UDP is not the recommended protocol for IPFIX and is intended for
> use in 
>>>> cases in which IPFIX is replacing an existing NetFlow
> infrastructure, 
>>>> with the following properties:
>>>>
>>>> 1. a dedicated network
>>>> 2. within a single administrative domain
>>>> 3. where SCTP is not available due to implementation constraints
>>>> 4. and the collector is as close as possible to the exporter.
>>>>
>>>> Would you like to see this text in the document or is the current
> text
>>>> at the beginning of 6.2 enough:
>>> [ ... snip ... ]
>>>
>>> Please put the above text into the document and explain "dedicated
>>> network" in more detail - that is crucial to ensuring the additional
>>> IPFIX traffic generated as a consequence of high traffic situations
>>> does not make the situation worse from a congestion standpoint.  In
>>> writing this text, please review
> draft-ietf-tsvwg-udp-guidelines-02.txt,
>>> although I suspect that much of it will not be applicable to IPFIX
>>> (it is not necessary to respond to the guidelines in that draft
>>> point-by-point, but it would be good to mention any that do apply).
>>>
>> ok, so the (proposed) text at beginning of 6.2 now is:
>>
>>
>>     UDP is useful in simple systems where an SCTP stack is not
> available,
>>     and where there is insufficient memory for TCP buffering.
>>
>>     However, UDP is not a reliable transport protocol, and IPFIX
> messages
>>     sent over UDP might be lost as with partially-reliable SCTP
> streams.
>>     UDP is not the recommended protocol for IPFIX and is intended for
> use
>>     in cases in which IPFIX is replacing an existing NetFlow
>>     infrastructure, with the following properties:
>>
>>     o  A dedicated network,
>>
>>     o  Within a single administrative domain,
>>
>>     o  Where SCTP is not available due to implementation constraints,
>>
>>     o  And the collector is as close as possible to the exporter.
>>
>> Note that because UDP itself provides no congestion control
> mechanisms,
>> it is up to the applications that use UDP to incorporate congestion
>> avoidance mechanisms. [RFC2309] discusses the dangers of
>> congestion-unresponsive flows and [draft-ietf-tsvwg-udp-guidelines-02]
>> provides guidelines for the designers of such applications.
> 
> I don't think that treatment of the UDP guidelines draft works, because
> (in a perfect world) that draft would have been guidance to the IPFIX
> protocol designers.  

shall I remove this last paragraph?

> in order to adjust its sending rate using TFRC (did I miss something?).
> 

Right, so I've asked Paul Aitken from Cisco about it and this is his answer:

---

We don't take any active measures not to congest. Rather, we expect the
user to design their network well.

We believe netflow export consumes 2-5% of the bandwidth of the sampled
traffic. So export over a dedicated 100M link should be able to support
netflow on 20-50 x 100M interfaces.

     When applications that exchange only a small number of messages with
     a destination at any time implement TFRC or one of the other
     congestion control schemes in Section 3.1.1, the network sees little
     benefit, because those mechanisms perform congestion control in a way
     that is only effective for longer transmissions.

---

Would you be fine with this motivation? Maybe we could add a reference 
to section 3.1.2 of the UDP guidelines in the text?

> Beyond this, I would add recommendations on message size (cf. UDP
> guidelines section 3.2) and checksums (SHOULD be used, cf. UDP
> guidelines section 3.4).  I think reliability is covered, and the
> "dedicated network" applicability statement above may render most
> of the middlebox concerns (section 3.5) inapplicable (administrator
> should configure them appropriately), or the resend interval might
> be adjusted to deal with this.
> 

Proposed text:

As recommended in [I-D.ietf-tsvwg-udp-guidelines] an application
SHOULD NOT send UDP messages that result in IP packets that exceed
the MTU of the path to the destination and SHOULD enable UDP 
  checksums (see sections 3.2 and 3.4 of [I-D.ietf-tsvwg-udp-guidelines] 
respectively).

thanks,
Elisa

---

From: Paul Aitken <[email-masked]>
Date: Thu, 06 Sep 2007 13:55:41 +0100

Lars,

> On 2007-9-6, at 14:51, ext Paul Aitken wrote:
>>>> As far as I can see, draft-ietf-tsvwg-udp-guidelines-02 contains no 
>>>> guidance other than:
>>
>>   "Applications that perform bulk transmission of data" (3.1.1)
>>
>> and
>>
>>   "When applications that exchange only a small number of messages with
>>    a destination at any time" (3.1.2.)
>>
>> Unfortunately "bulk transmission", "a small number of messages" and 
>> "at any time" don't seem to be clarified or defined in any way.
> 
> the basis of TFRC and TCP-like congestion control is to sample the path 
> over several subsequent RTTs during which data is exchanged, in order to 
> determine a sending rate which the path at its current load can support. 
> For this to be effective, an application needs to actually have enough 
> data to transmit to a destination to perform this iterative probing. The 
> draft calls these sorts of applications "bulk transfers."
> 
> Applications that don't transmit sufficient data ("low-datarate 
> applications") aren't efficiently controlled by mechanisms such as TFRC. 
> For example, DNS-style query-response applications that communicate with 
> many different peers over time aren't well suited for TFRC.
> 
>> (Nor for that matter is there any distinction between a small number 
>> of large messages and a large number of small messages, though both 
>> may ultimately carry the same amount of data.)
> 
> Maybe the current draft doesn't make this distinction sufficiently clear 
> yet?

It seems to me that there's an opportunity for you to clarify this, yes.

>> So yes, as you assert, "IPFIX will send many packets to a 
>> destination". Of course, that's expected of most protocols, is it not?
> 
> Not necessarily. There are large number of UDP-based signaling and 
> lookup protocols that don't exchange more than a request-response 
> exchange with a destination. Applications that exchange a lot of data 
> over UDP are actually quite rare, because TCP is much better suited to 
> that purpose.
> 
> For IPFIX, I'd expect it to transmit a more or less steady flow of 
> packets to a destination. (Depending on what it is configure to sample, 
> of course.) I'd hence categorize it into the "bulk transfer" class of 
> applications.

What's a "steady flow"? "Steady" means "regular" or "constant" without 
implying any amount, so it seems to me that it could still be "a small 
number of messages ... at any time".

>> And that could easily be "a small number of messages ... at any time", 
>> depending how exactly those terms are defined. Hopefully you can offer 
>> us some clarification?
> 
> I hope the above made it clearer.

In short, I believe your definitions could (and should) be far more 
robust, because right now they're very much open to subjective 
interpretation.

>> But for now, since we estimate that NetFlow v9 export consumes a mere 
>> 2-5% of the bandwidth of a monitored channel, I consider that it does 
>> fall into the "Low Data-Volume" category.
> 
> First, do you have any data that supports that 2-5% assumption?

The info came from discussions with our customers. FWIW, we generally 
expect around 2%.

> Second, 2-5% of the rate of a high-speed path may still be quite a bit 
> of traffic.

Absolutely - though in relative terms it's still a whole lot less than 
the traffic that's being measured.

> More importantly, the path to the IPFIX destination may have 
> very different characteristics from the path on which IPFIX is 
> monitoring the traffic, and the IPFIX traffic can hence significantly 
> interfere with other traffic sharing that path. Especially because IPFIX 
> over UDP won't reduce its send rate in response to congestion.

Which is why cisco recommends exporting NetFlow over a dedicated link.

> Note that we're not singling out IPFIX here. The forthcoming revisions 
> to the syslog documents, for example, will have the following statement 
> ("TLS" is "TLS over TCP"):
> 
>    Because syslog can generate unlimited amounts of data, transferring this
>    data over UDP is generally problematic, because UDP lacks congestion
>    control mechanisms. Congestion control mechanisms that respond to
>    congestion by reducing traffic rates and establish a degree of fairness
>    between flows that share the same path are vital to the stable operation
>    of the Internet [RFC2914]. This is why the syslog TLS transport is
>    REQUIRED to implement and RECOMMENDED for general use.
> 
>    The only environments where the syslog UDP transport MAY be used as an
>    alternative to the TLS transport are managed networks, where the network
>    path has been explicitly provisioned for UDP syslog traffic through
>    traffic engineering mechanisms, such as rate limiting or capacity
>    reservations. In all other environments, the TLS transport SHOULD be used.
> 
> I believe a similar statement for IPFIX would be appropriate.

Agreed; I'd be happy with that.

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

---

From: Lars Eggert <[email-masked]>
Date: Thu, 6 Sep 2007 15:19:42 +0300

>`InetAddress' object should have an accompanied preceding
>`InetAdressType' object
>./MGMD-STD-MIB:758: [5] {inetaddress-inetaddresstype} warning:
>`InetAddress' object should have an accompanied preceding
>`InetAdressType' object
>./MGMD-STD-MIB:844: [5] {inetaddress-inetaddresstype} warning:
>`InetAddress' object should have an accompanied preceding
>`InetAdressType' object
>./MGMD-STD-MIB:862: [5] {inetaddress-inetaddresstype} warning:
>`InetAddress' object should have an accompanied preceding
>`InetAdressType' object
>./MGMD-STD-MIB:917: [5] {inetaddress-inetaddresstype} warning:
>`InetAddress' object should have an accompanied preceding
> `InetAdressType' object	
>Bert Wijnen  
>
>  
>
>>-----Original Message-----
>>From: The IESG [mailto:[email-masked]]
>>Sent: Thursday, August 30, 2007 5:24 PM
>>To: IETF-Announce
>>Cc: [email-masked]
>>Subject: Last Call: draft-ietf-magma-mgmd-mib (Multicast Group 
>>Membership Discovery MIB) to Proposed Standard
>>
>>The IESG has received a request from the Multicast & Anycast Group 
>>Membership WG (magma) to consider the following document:
>>
>>- 'Multicast Group Membership Discovery MIB '
>>   <draft-ietf-magma-mgmd-mib-10.txt> as a Proposed Standard
>>
>>The IESG plans to make a decision in the next few weeks, and solicits 
>>final comments on this action.  Please send substantive comments to 
>>the [email-masked] mailing lists by 2007-09-13. Exceptionally, comments
>>    
>>
>
>  
>
>>may be sent to [email-masked] instead. In either case, please retain 
>>the beginning of the Subject line to allow automated sorting.
>>
>>The file can be obtained via
>>http://www.ietf.org/internet-drafts/draft-ietf-magma-mgmd-mib-10.txt
>>
>>
>>IESG discussion can be tracked via
>>https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
>>w_id&dTag=
>>10603&rfc_flag=0
>>    
>>

---

From: Lars Eggert <[email-masked]>
Date: Thu, 6 Sep 2007 15:19:42 +0300

Paul,

On 2007-9-6, at 14:51, ext Paul Aitken wrote:
>>> As far as I can see, draft-ietf-tsvwg-udp-guidelines-02 contains  
>>> no guidance other than:
>

the basis of TFRC and TCP-like congestion control is to sample the  
path over several subsequent RTTs during which data is exchanged, in  
order to determine a sending rate which the path at its current load  
can support. For this to be effective, an application needs to  
actually have enough data to transmit to a destination to perform  
this iterative probing. The draft calls these sorts of applications  
"bulk transfers."

Applications that don't transmit sufficient data ("low-datarate  
applications") aren't efficiently controlled by mechanisms such as  
TFRC. For example, DNS-style query-response applications that  
communicate with many different peers over time aren't well suited  
for TFRC.

> (Nor for that matter is there any distinction between a small  
> number of large messages and a large number of small messages,  
> though both may ultimately carry the same amount of data.)

Maybe the current draft doesn't make this distinction sufficiently  
clear yet?

Not necessarily. There are large number of UDP-based signaling and  
lookup protocols that don't exchange more than a request-response  
exchange with a destination. Applications that exchange a lot of data  
over UDP are actually quite rare, because TCP is much better suited  
to that purpose.

For IPFIX, I'd expect it to transmit a more or less steady flow of  
packets to a destination. (Depending on what it is configure to  
sample, of course.) I'd hence categorize it into the "bulk transfer"  
class of applications.

> And that could easily be "a small number of messages ... at any  
> time", depending how exactly those terms are defined. Hopefully you  
> can offer us some clarification?

> But for now, since we estimate that NetFlow v9 export consumes a  
> mere 2-5% of the bandwidth of a monitored channel, I consider that  
> it does fall into the "Low Data-Volume" category.

Second, 2-5% of the rate of a high-speed path may still be quite a  
bit of traffic. More importantly, the path to the IPFIX destination  
may have very different characX-Spam-Score: 0.0 (/)
X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba
X-Mailman-Approved-At: Thu, 06 Sep 2007 08:56:01 -0400
Cc: [email-masked], [email-masked], [email-masked],
	[email-masked], ext Elisa Boschi <[email-masked]>,
	[email-masked], [email-masked],
	[email-masked], Benoit Claise <[email-masked]>, [email-masked]
Subject: Re: [tsv-dir] Re: Transport Directorate review of
	draft-ietf-ipfix-implementation-guidelines-06.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0415983316=="
Errors-To: [email-masked]

Paul,

On 2007-9-6, at 14:51, ext Paul Aitken wrote:
>>> As far as I can see, draft-ietf-tsvwg-udp-guidelines-02 contains  
>>> no guidance other than:
>

the basis of TFRC and TCP-like congestion control is to sample the  
path over several subsequent RTTs during which data is exchanged, in  
order to determine a sending rate which the path at its current load  
can support. For this to be effective, an application needs to  
actually have enough data to transmit to a destination to perform  
this iterative probing. The draft calls these sorts of applications  
"bulk transfers."

Applications that don't transmit sufficient data ("low-datarate  
applications") aren't efficiently controlled by mechanisms such as  
TFRC. For example, DNS-style query-response applications that  
communicate with many different peers over time aren't well suited  
for TFRC.

> (Nor for that matter is there any distinction between a small  
> number of large messages and a large number of small messages,  
> though both may ultimately carry the same amount of data.)

Maybe the current draft doesn't make this distinction sufficiently  
clear yet?

Not necessarily. There are large number of UDP-based signaling and  
lookup protocols that don't exchange more than a request-response  
exchange with a destination. Applications that exchange a lot of data  
over UDP are actually quite rare, because TCP is much better suited  
to that purpose.

For IPFIX, I'd expect it to transmit a more or less steady flow of  
packets to a destination. (Depending on what it is configure to  
sample, of course.) I'd hence categorize it into the "bulk transfer"  
class of applications.

> And that could easily be "a small number of messages ... at any  
> time", depending how exactly those terms are defined. Hopefully you  
> can offer us some clarification?

> But for now, since we estimate that NetFlow v9 export consumes a  
> mere 2-5% of the bandwidth of a monitored channel, I consider that  
> it does fall into the "Low Data-Volume" category.

Second, 2-5% of the rate of a high-speed path may still be quite a  
bit of traffic. More importantly, the path to the IPFIX destination  
may have very different characteristics from the path on which IPFIX  
is monitoring the traffic, and the IPFIX traffic can hence  
significantly interfere with other traffic sharing that path.  
Especially because IPFIX over UDP won't reduce its send rate in  
response to congestion.

Note that we're not singling out IPFIX here. The forthcoming  
revisions to the syslog documents, for example, will have the  
following statement ("TLS" is "TLS over TCP"):

    Because syslog can generate unlimited amounts of data,  
transferring this
    data over UDP is generally problematic, because UDP lacks congestion
    control mechanisms. Congestion control mechanisms that respond to
    congestion by reducing traffic rates and establish a degree of  
fairness
    between flows that share the same path are vital to the stable  
operation
    of the Internet [RFC2914]. This is why the syslog TLS transport is
    REQUIRED to implement and RECOMMENDED for general use.

    The only environments where the syslog UDP transport MAY be used  
as an
    alternative to the TLS transport are managed networks, where the  
network
    path has been explicitly provisioned for UDP syslog traffic through
    traffic engineering mechanisms, such as rate limiting or capacity
    reservations. In all other environments, the TLS transport SHOULD  
be used.

Lars

---

From: Paul Aitken <[email-masked]>
Date: Thu, 06 Sep 2007 12:51:28 +0100

Lars,

and

Unfortunately "bulk transmission", "a small number of messages" and "at 
any time" don't seem to be clarified or defined in any way.

(Nor for that matter is there any distinction between a small number of 
large messages and a large number of small messages, though both may 
ultimately carry the same amount of data.)

So yes, as you assert, "IPFIX will send many packets to a destination". 
Of course, that's expected of most protocols, is it not?

Cheers.

---

From: [email-masked]
Date: Thu, 6 Sep 2007 10:41:02 -0400

Elisa,

> > Note that we're not singling out IPFIX here. The forthcoming
revisions 
transferring this
fairness
operation
as an
network
be used.
> we currently have the  following statement for IPFIX/UDP:
> 
> ---
available,
messages
streams.
use
>     o  within a single administrative domain,
> 
>     o  where SCTP is not available due to implementation constraints,
> 
>     o  and the collector is as close as possible to the exporter.
> ---
> 
> Would the addition of the text below be an acceptable solution?
> 
> ---
> mechanisms, it is recommended to use UDP transport only on managed 
> networks, where the network path has been explicitly provisioned for 
> IPFIX traffic through traffic engineering mechanisms, such as rate 
> limiting or capacity reservations.
> ---

While Lars (as AD) is the final authority (e.g., on whether "it is
recommended" above is strong enough language), I'd like to add a
couple of sentences to recognize "dedicated network that hosted
a NetFlow implementation" as a common case (to help out the
network administrators who actually have to make this work):

	An important example of an explicitly provisioned managed
	network for IPFIX is use of IPFIX to replace a functioning
	NetFlow implementation on a dedicated network.  In this
	situation, the dedicated network should be provisioned in
	accordance with the NetFlow deployment experience that flow
	export traffic generated by monitoring an interface will
	amount to 2-5% of the monitored interface's bandwidth.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Elisa Boschi <[email-masked]>
Date: Thu, 06 Sep 2007 15:02:13 +0200

Lars, Paul, David,

---
    UDP is useful in simple systems where an SCTP stack is not available,
    and where there is insufficient memory for TCP buffering.

    However, UDP is not a reliable transport protocol, and IPFIX messages
    sent over UDP might be lost as with partially-reliable SCTP streams.
    UDP is not the recommended protocol for IPFIX and is intended for use
    in cases in which IPFIX is replacing an existing NetFlow
    infrastructure, with the following properties:

    o  A dedicated network,

---

thanks,
Elisa

---

From: Elisa Boschi <[email-masked]>
Date: Fri, 07 Sep 2007 11:34:59 +0200

David, all,

> 	amount to 2-5% of the monitored interface's bandwidth.

OK, thanks, added. I copy below the current version of the UDP section. 
Let me know if you agree with it. The last changes are the beginning of 
the section.

One last open point is whether the following text, or something similar, 
should be added or not:

As recommended in [I-D.ietf-tsvwg-udp-guidelines] an application
SHOULD NOT send UDP messages that result in IP packets that exceed
the MTU of the path to the destination and SHOULD enable UDP checksums 
(see sections 3.2 and 3.4 of [I-D.ietf-tsvwg-udp-guidelines] respectively).

thanks,
Elisa

---

6.2.  UDP

    o  A dedicated network,

    An important example of an explicitly provisioned managed network for
    IPFIX is use of IPFIX to replace a functioning NetFlow implementation
    on a dedicated network.  In this situation, the dedicated network
    should be provisioned in accordance with the NetFlow deployment
    experience that flow export traffic generated by monitoring an
    interface will amount to 2-5% of the monitored interface's bandwidth.

    Since IPFIX assumes reliable transport of templates over SCTP, this
    necessitates some changes for IPFIX template management over UDP.
    Templates sent from the Exporting Process to the Collecting Process
    over UDP MUST be resent at regular time intervals; these intervals
    MUST be configurable.

    We recommend a default Template resend time of 10 minutes,
    configurable between 1 minute and 1 day.

    Note that this could become an interoperability problem, e.g. if an
    Exporter re-sends Templates once per day, while a Collector expires
    Templates hourly, then they may both be IPFIX-compatible, but not be
    interoperable.

    Retransmission time intervals that are too short waste bandwidth on
    unnecessary template retransmissions.  On the other hand, time
    intervals that are too long introduce additional costs or risk of
    data loss by potentially requiring the Collector to cache more data
    without having theTemplates available to decode it.

    To increase reliability and limit the amount of potentially lost data
    the Exporting Process MAY resend additional templates using a packet-
    based schedule.  In this case Templates are resent depending on the
    number of packets sent.  Similarly to the time interval, resending a
    Template every few packets introduces additional overhead while
    resending after a lange amount of packets have already been sent
    means high costs due to the data caching and potential data loss.

    We recommend a default Template resend interval of 20 packets,
    configurable between 1 and 1000 packets.

    Note that a sufficiently small resend time or packet interval may
    cause a system to become stuck, continually re-sending templates.
    e.g., if the resend packet interval is 2 (i.e., templates are to be
    sent in every other packet) but more than two packets are required to
    send all the templates, then the resend interval will have expired by
    the time the templates have been sent, and templates will be sent
    continuously - possibly preventing any data from being sent at all.
    Therefore the Template resend intervals should be considered from the
    last data packet, and should not be tied to specific sequence
    numbers.

    The following may be done to mitigate message loss:

    o  Move the Collector topologically closer to the Exporter.

    o  Increase the bandwidth of the links through which the Data Records
       are exported.

    o  Use sampling, filtering, or aggregation in the Metering Process to
       reduce the amount of exported data.

    o  Increase the buffer size at the Collector and/or the Exporter.

    Before using a Template for the first time, the Exporter may send it
    in several different IPFIX Messages spaced out over a period of time
    in order to increase the likelihood that the Collector has received
    the Template.

    Template Withdraw messages MUST NOT be sent over UDP; the Exporter
    must rely on expiration at the Collector to expire old Templates or
    to reuse Template Ids.

    We recommend that the collector implements a template expiry of three
    times the Exporter refresh rate.

    However, since the IPFIX protocol doesn't provide any mechanism for
    the Exporter to convey any information about the Template expiry time
    to the Collector, configuration must be done out of band.

    If no out of band configuration is made, we recommend to initially
    set a template expiry time at the Collector of 60 minutes.  The
    Collecting Process MAY estimate each Exporting Process's resend time
    and adapt the expiry time for the corresponding Templates
    accordingly.

---

From: Simon Leinen <[email-masked]>
Date: Fri, 07 Sep 2007 17:28:27 +0200

I'm a bit wary to step in this discussion, but anyway.  Here's a little
input from an operator who has been using various variants of Netflow
over the years.  Netflow is rather like IPFIX over UDP as far as
congestion (non-)handling is concerned.

> First, do you have any data that supports that 2-5% assumption?

That looks like a "typical" rate for unsampled IPFIX.  If you use
sampling, you can limit the export rate to some arbitrary fraction of
the monitored data rate.

For unsampled IPFIX in a typical configuration (with ~5-tuple flows
like (non-aggregated "inflexible") Netflow), you can always construct
traffic where each 28-byte packet generates a flow record.  On Netflow
v5 these records are 48 bytes each, for IPFIX I assume it's somehow
similar.

On the other hand, the Netflow implementations I know (on routers)
have a hard limit on how fast they can create and/or export flows,
which is much lower than typical link rates.  For example, our current
routers export a quarter of their (hardware) flow table every second,
and the table is limited to 256 Kflows.  So they never send more than
32 Kflows per second, corresponding to roughly 12.6 Mb/s with Netflow
v5.  Not a problem as long as the export traffic stays in our Gigabit
backbone.  (But boy, is this traffic bursty! Which is why I'd still
prefer TCP in this case.)

> Especially because IPFIX over UDP won't reduce its send rate in

Good point.

> to the syslog documents, for example, will have the  following
> statement ("TLS" is "TLS over TCP"):

>    transferring this data over UDP is generally problematic, because
>    UDP lacks congestion control mechanisms. Congestion control
>    mechanisms that respond to congestion by reducing traffic rates
>    and establish a degree of fairness between flows that share the
>    same path are vital to the stable operation of the Internet
>    [RFC2914]. This is why the syslog TLS transport is REQUIRED to
>    implement and RECOMMENDED for general use.

>    as an alternative to the TLS transport are managed networks,
>    where the network path has been explicitly provisioned for UDP
>    syslog traffic through traffic engineering mechanisms, such as
>    rate limiting or capacity reservations. In all other
>    environments, the TLS transport SHOULD be used.

> I believe a similar statement for IPFIX would be appropriate.

I wouldn't object!
-- 
Simon.