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

["Romascanu, Dan (Dan)" <[e-mail]>]

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.
> >>
> >>
> >>     
> 
>