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.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf