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)
"When applications that exchange only a small number of messages
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
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
(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
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.
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.
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?
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,
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
between flows that share the same path are vital to the stable
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
alternative to the TLS transport are managed networks, where the
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
I believe a similar statement for IPFIX would be appropriate.
Description: S/MIME cryptographic signature
Ietf mailing list