On 2007-9-6, at 12:01, ext Elisa Boschi wrote:
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:
I don't see IPFIX falling into this category. IPFIX will send many
packets to a destination. (And even if IPFIX fell into this category,
it'd need to implement congestion control mechanisms for low-datarate
applications, which the draft also gives guidelines for.)
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?
Lars
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf