Re: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on performance and capacity

[Benoit Claise <[e-mail]>]

Dan,
> Please find below the AD review for
> draft-ietf-ipfix-export-per-sctp-stream-02. The document is mature
> enough to go to IETF Last Call. Unless there are any special comments or
> concerns I will send it to IETF Last Call by tomorrow. 
>
> Please consider the comments below together with the other IETF Last
> Call comments. The comments are divided into Technical and Editorial
>
> T1. There is not information concerning the impact on performance and
> capacity of the reporting and collecting processes. Should we expect any
> considerable impact on performance and/or capacity? If any
> implementation experience is available I would suggest that we record
> it. 
>   
Collecting information from the authors of 
draft-stewart-tsvwg-sctpstrrst and 
draft-ietf-ipfix-export-per-sctp-stream-02, here are the conclusions:
* We were not too sure what is meant by "performance and capacity" in 
this context.
* If the question is about: What's the impact of additional SCTP streams 
in an existing session versus opening a new SCTP session? The impact is 
minor:
- You have of course a message exchange to add the streams.
- You end up adding 16-24 bytes per stream.
- It is more lightweight to set up additional streams compared to 
setting up a new association.
The only thing that comes into my mind is throughput which
* If the question is about the throughput that could be impaired by 
processing overhead and message overhead.
- With respect of processing overhead, I have no idea how the 
utilization of a large number of streams influences the performance of 
the SCTP socket. I could imagine that a lot of state information must be 
stored.
- With respect of message overhead, we can say that the fact that we 
discourage multiplexing templates and data records of different template 
ids may lead to a larger message overhead. If the data record rate is 
low for a specific template, the exporting process might not be able to 
optimally fill the IPFIX messages. Hence, we have more overhead due to 
additional IPFIX message headers and SCTP chunk headers.

Is this what you have in mind?

Regards, Benoit.