David,
We're getting close, but I think some more work on UDP guidelines
is still appropriate. As the existence of the UDP guidelines draft
indicates, this is a topic of current interest in the Transport Area.
see inline
> Section 6.2: UDP
>
> [2] I don't see any discussion of congestion control in here.
> Something needs to be done to avoid a high rate IPFIX protocol
> session over UDP worsening a congestion situation because not
> only is the IPFIX flow non-responsive to congestion, but
> congested conditions may increase the volume of IPFIX data
> to be reported. At the very least, this draft should repeat
> and reinforce the discussion in Section 10.3.1 of
> draft-ietf-ipfix-protocol-24.txt, which says that UDP should
> not be used over congestion sensitive network paths - I'm not
> thrilled about that approach, but the ipfix-protocol draft
> is already in the RFC Editor Queue. A general recommendation
> against UDP when TCP or SCTP is possible may be appropriate,
> and the first item in Section 10.1 is related to this concern,
> as it requires availability of a congestion-controlled protocol.
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:
1. a dedicated network
2. within a single administrative domain
3. where SCTP is not available due to implementation constraints
4. and the collector is as close as possible to the exporter.
Would you like to see this text in the document or is the current
text
at the beginning of 6.2 enough:
[ ... snip ... ]
Please put the above text into the document and explain "dedicated
network" in more detail - that is crucial to ensuring the additional
IPFIX traffic generated as a consequence of high traffic situations
does not make the situation worse from a congestion standpoint. In
writing this text, please review
draft-ietf-tsvwg-udp-guidelines-02.txt,
although I suspect that much of it will not be applicable to IPFIX
(it is not necessary to respond to the guidelines in that draft
point-by-point, but it would be good to mention any that do apply).
ok, so the (proposed) text at beginning of 6.2 now is:
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.
Note that because UDP itself provides no congestion control
mechanisms,
it is up to the applications that use UDP to incorporate congestion
avoidance mechanisms. [RFC2309] discusses the dangers of
congestion-unresponsive flows and [draft-ietf-tsvwg-udp-guidelines-02]
provides guidelines for the designers of such applications.
I don't think that treatment of the UDP guidelines draft works, because
(in a perfect world) that draft would have been guidance to the IPFIX
protocol designers.
shall I remove this last paragraph?
To be specific, how would an application using
IPFIX over UDP obtain the packet loss information needed to implement
TFRC as recommended in Section 3.1.1 of the UDP guidelines draft?
The IPFIX implementation guidelines draft says:
The Collecting Process SHOULD use the Sequence Number in the IPFIX
Message header to determine whether any messages are lost.
but I don't see how the Exporting Process can learn this information
in order to adjust its sending rate using TFRC (did I miss something?).
A discussion of how to implement TFRC or what to do on a dedicated
network when TFRC is not implemented would be useful. The fact that
there was a working NetFlow implementation might be helpful in
configuring IPFIX to not congest the dedicated network.
Right, so I've asked Paul Aitken from Cisco about it and this is his answer:
---
We don't take any active measures not to congest. Rather, we expect the
user to design their network well.
We believe netflow export consumes 2-5% of the bandwidth of the sampled
traffic. So export over a dedicated 100M link should be able to support
netflow on 20-50 x 100M interfaces.
IPFIX will be very similar.
Looking at draft-ietf-tsvwg-udp-guidelines-02, I see TFRC recommended
for "Bulk Transfer Applications" (section 3.1.1).
However, I think that netflow and IPFIX export fall into the "Low
Data-Volume Applications" category (section 3.1.2) which says:
When applications that exchange only a small number of messages with
a destination at any time implement TFRC or one of the other
congestion control schemes in Section 3.1.1, the network sees little
benefit, because those mechanisms perform congestion control in a way
that is only effective for longer transmissions.
So I don't think discussion of how to implement TFRC for IPFIX/UDP is
relevant.
---
I agree with him on this.
Would you be fine with this motivation? Maybe we could add a reference
to section 3.1.2 of the UDP guidelines in the text?
Beyond this, I would add recommendations on message size (cf. UDP
guidelines section 3.2) and checksums (SHOULD be used, cf. UDP
guidelines section 3.4). I think reliability is covered, and the
"dedicated network" applicability statement above may render most
of the middlebox concerns (section 3.5) inapplicable (administrator
should configure them appropriately), or the resend interval might
be adjusted to deal with this.
Proposed text:
As recommended in [I-D.ietf-tsvwg-udp-guidelines] an application
SHOULD NOT send UDP messages that result in IP packets that exceed
the MTU of the path to the destination and SHOULD enable UDP
checksums (see sections 3.2 and 3.4 of [I-D.ietf-tsvwg-udp-guidelines]
respectively).
thanks,
Elisa
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf