Hi Tobias, Thanks for your comments. Some replies inline. Tobias Limmer wrote:
Hi Benoit, all,I've also got a few comments on the draft ipfix-export-per-sctp- stream-04:2.3. Limitations:"This method requires multiple SCTP streams in the association between the Exporting and Collecting Process, ideally one per Template."No - if we had only one Template in the association, we would not need multiple SCTP streams.
Indeed, this formulation can be relaxed a little bit.
3.1.1. IPFIX Protocol Specifications Limitation:"Note that a workaround allowed by the IPFIX specifications [RFC5101] is to use only one Template Record per SCTP Transport Session, at the cost of multiplying the number of SCTP Transport Sessions when multiple Template Records are required."This paragraph sounds a little misplaced, as it already mentions the performance impact. After reading it, I was wondering what other method would be proposed in this draft.
Not sure if you got the paragraph right. It talks about SCTP Transport Sessions, not SCTP streams. Using different Transport Sessions requires indeed much more overhead (e.g., multiple sockets) than just having multiple streams in one Transport Session.
4.2. Template Management:"Any Data Sets associated with a Template Record MUST be sent on the same SCTP stream on which the Template Record was sent."According to rfc5101, an Options Template Record is a Template Record. Later in the same section you specify: "When the Options Template and associated Data Records are sent in different SCTP streams, [...]".Isn't this a contradiction, or am I missing something here?
This is a flaw of IPFIX terminology.In the text, we tried to consistently use "(Options) Template" if we talk about both Options and non-Options Templates. The sentence above is just about non-Options Templates.
Not sure, how we can make this more comprehensible. Maybe a note in the terminology section?
4.5. The Collecting Process's Side:"3. A Data Record is received unreliably although it is expected to be sent reliably (due to a previously received Data Record associated with the Data Record Reliability Options Template)."Is it possible for the receiving side of a SCTP connection to determine which SCTP messages were sent unreliably? I did not find any indication of that in rfc3758. The receiving side only knows if complete messages or fragments are skipped.
I think you are right. We need to check. Regards, Gerhard
4.5. The Collecting Process's Side: "In the case where the Exporting Process does not support the [...]" This paragraph is a duplicate. 6. Examples:In Figure 3, you seem to use the Options Reliability Template 257 (defined in Figure 1) that was received in another stream. A small remark would be good which indicates, that all streams belong to the same SCTP association.Thanks, Tobi -- Dipl.-Inf. Tobias Limmer Chair for Computer Networks and Communication Systems Universität Erlangen-Nürnberg Martensstr. 3, D-91058 Erlangen, Germany Phone: +49-9131-8527931 Fax: +49-9131-8527409 eMail: limmer .at. informatik.uni-erlangen.de URL: http://www7.informatik.uni-erlangen.de/~limmer _______________________________________________ IPFIX mailing list IPFIX at ietf.org https://www.ietf.org/mailman/listinfo/ipfix
-- Dipl.-Ing. Gerhard Münz Chair for Network Architectures and Services (I8) Technische Universität München - Department of Informatics Boltzmannstr. 3, 85748 Garching bei München, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz at net.in.tum.de WWW: http://www.net.in.tum.de/~muenz
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature