Re: [tsv-dir] Re: Transport Directorate review of draft-ietf-ipfix-imple

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  
> 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?
> 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 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.

Lars

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf