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

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Sun, 21 June 2009 12:42 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A063E3A6965 for <ipfix@core3.amsl.com>; Sun, 21 Jun 2009 05:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.454
X-Spam-Level:
X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjqd3tiZ-Dw2 for <ipfix@core3.amsl.com>; Sun, 21 Jun 2009 05:42:12 -0700 (PDT)
Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id A267B3A68E5 for <ipfix@ietf.org>; Sun, 21 Jun 2009 05:42:11 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.42,262,1243828800"; d="scan'208,217"; a="164925851"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 21 Jun 2009 08:42:25 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Jun 2009 08:42:24 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9F26D.ADFCA94C"
Date: Sun, 21 Jun 2009 14:42:02 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A04017D345E@307622ANEX5.global.avaya.com>
In-Reply-To: <4A3E282E.1050302@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on performance and capacity
thread-index: AcnybD90xAzeNjPYRT2IYiKTxtwRIAAAUfDg
References: <EDC652A26FB23C4EB6384A4584434A0401790AFE@307622ANEX5.global.avaya.com> <4A3805EC.3010702@cisco.com> <EDC652A26FB23C4EB6384A4584434A04017D2D8F@307622ANEX5.global.avaya.com> <4A3C25E4.2040005@cisco.com> <EDC652A26FB23C4EB6384A4584434A04017D3444@307622ANEX5.global.avaya.com> <4A3E282E.1050302@cisco.com>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Benoit Claise <bclaise@cisco.com>
Cc: IETF IPFIX Working Group <ipfix@ietf.org>
Subject: Re: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on performance and capacity
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipfix>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jun 2009 12:42:13 -0000

The document was sent to IETF Last Call and the Last Call was issued on
6/16. Please wait until the Last Call expires (6/30) to make this change
together with all other changes following last call comments. 
 
Regards,
 
Dan
 


________________________________

	From: Benoit Claise [mailto:bclaise@cisco.com] 
	Sent: Sunday, June 21, 2009 3:32 PM
	To: Romascanu, Dan (Dan)
	Cc: IETF IPFIX Working Group
	Subject: Re: [IPFIX] AD Review of
draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on performance and
capacity
	
	
	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:bclaise@cisco.com] 
			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:bclaise@cisco.com]
				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.