Re: [tsv-dir] Re: Transport Directorate review of draft-ietf-ipfix-implementation-guidelines-06.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]