Lars, Paul, David,
Lars Eggert wrote:
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.
we currently have the following statement for IPFIX/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 close as possible to the exporter.
---
Would the addition of the text below be an acceptable solution?
---
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.
---
thanks,
Elisa
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf