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

[Benoit Claise <[e-mail]>]

Dan
> Hi Benoit,
>
> Yes, this is the type of information that I was looking for. My reading
> of your answer is that the impact of adding SCTP streams in an existing
> session versus opening a new SCTP session is minor, with a possible plus
> of efficiency at setup time. Processing overhead and message overhead
> may potentially be a problem, and care should be exercised in deployment
> in order to understand the effects. 
>
> Can we add corresponding text on this? 
>   
Here is our proposal:

What is the performance impact regarding the implementation of these 
specifications compared to the IPFIX protocol [RFC5101]?

Although adding the new SCTP streams requires a message exchange, it is 
more lightweight to set up additional SCTP streams than to set up a new 
SCTP association since the only overhead of adding stream(s) to an 
existing SCTP association is the addition of 16-24 more bytes (allocated 
in the SCTP association, a single time), whereas setting up a new SCTP 
association implies more overhead.

In terms of of throughput impact, the fact that these specifications 
discourage multiplexing Templates and Data Records of different Template 
IDs may lead to a slightly larger IPFIX Message overhead. If the Data 
Record rate is low for a specific Template (hence a specific SCTP 
stream), the Exporting Process might not be able to fill the IPFIX 
Messages as fully as possible. In such a situation, we could potentially 
have an overhead due to additional IPFIX Message headers and SCTP chunk 
headers.

Finally, with respect to the processing overhead on the Exporter, a lot 
of state information must be stored when a large number of SCTP streams 
are used with an SCTP association. The authors have not yet been able to 
compare the performance impact of multiple streams within an SCTP 
association versus opening the same number of independent SCTP associations.

Fine with you?

Regards, Benoit.
> Thanks and Regards,
>
> Dan
>
>
>   
>> -----Original Message-----
>> From: Benoit Claise [mailto:[e-mail]] 
>> Sent: Tuesday, June 16, 2009 11:52 PM
>> To: Romascanu, Dan (Dan)
>> Cc: IETF IPFIX Working Group; Randall Stewart; Peter Lei 
>> (peterlei); Michael Tuexen
>> Subject: Re: [IPFIX] AD Review of 
>> draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on 
>> performance and capacity
>>
>> 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.
>>
>>
>>