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:"Applications that perform bulk transmission of data" (3.1.1) and"When applications that exchange only a small number of messages witha 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?
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, transferring this
data over UDP is generally problematic, because UDP lacks congestion control mechanisms. Congestion control mechanisms that respond tocongestion 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 capacityreservations. In all other environments, the TLS transport SHOULD be used.
I believe a similar statement for IPFIX would be appropriate. Lars
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf