Scott,
we received similar comments during the transport directorate review of the
IPFIX implementation guidelines. The new revision of the document, now
available at:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-implementation-guidelines-07.txt
might address your concerns.
I'm copying the UDP section here below for your convenience.
Elisa
---
6.2. UDP
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 topographically close as possible to the
exporter.
Note that because UDP itself provides no congestion control
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.
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.
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).
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 the Templates 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 data packets sent. Similarly to the time interval,
resending a Template every few packets introduces additional overhead
while resending after a large 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 Collecting Process SHOULD use the Sequence Number in the IPFIX
Message header to determine whether any messages are lost.
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
