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

[Benoit Claise <[e-mail]>]

Dan,

Thanks. I'll apply the changes
What is the next step?
You mentioned on your June 15th:

    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. 

Do you want a quick updated version?

Regards, Benoit

> This looks fine to me. As an editorial observation, it is good to avoid
> 'personalized' style in such specifications like the usage of 'we' and
> 'the authors'. Impersonal modes are better. 
>
> Thanks for addressing this comment. 
>
> Dan
>  
>
>   
>> -----Original Message-----
>> From: Benoit Claise [mailto:[e-mail]] 
>> Sent: Saturday, June 20, 2009 2:57 AM
>> 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
>>     
>>> 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.
>>>>
>>>>
>>>>     
>>>>         
>>