Subject: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 15 Jun 2009 14:55:55 +0200

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. 

E1. idnits complains about a number of IPR boilerplate issues and
obsolete references issues: 

tmp/draft-ietf-ipfix-export-per-sctp-stream-02.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
 
------------------------------------------------------------------------
----

  ** You're using the IETF Trust Provisions Section 6.b License Notice
from
     10 Nov 2008 rather than the newer Notice from 12 Feb 2009, which is
     required now.  (See http://trustee.ietf.org/license-info/)

  Checking nits according to
http://www.ietf.org/ietf/1id-guidelines.txt:
 
------------------------------------------------------------------------
----

     No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
 
------------------------------------------------------------------------
----

     No issues found here.

  Miscellaneous warnings:
 
------------------------------------------------------------------------
----

  == The document seems to lack a disclaimer for pre-RFC5378 work, but
was
     first submitted before 10 November 2008.  Should you add the
disclaimer?
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.). 

     trust-12-feb-2009 Section 6.c.iii text:
     "This document may contain material from IETF Documents or IETF
      Contributions published or made publicly available before November
      10, 2008.  The person(s) controlling the copyright in some of this
      material may not have granted the IETF Trust the right to allow
      modifications of such material outside the IETF Standards Process.

      Without obtaining an adequate license from the person(s)
      controlling the copyright in such materials, this document may not
      be modified outside the IETF Standards Process, and derivative
      works of it may not be created outside the IETF Standards Process,
      except to format it for publication as an RFC or to translate it
      into languages other than English."

  Checking references for intended status: Informational
 
------------------------------------------------------------------------
----

  == Outdated reference: draft-ietf-psamp-sample-tech has been published
as
     RFC 5475

  == Outdated reference: draft-ietf-ipfix-architecture has been
published as
     RFC 5470

  == Outdated reference: draft-ietf-ipfix-as has been published as RFC
5472

  == Outdated reference: draft-ietf-psamp-protocol has been published as
RFC
     5476

  == Outdated reference: draft-ietf-psamp-framework has been published
as RFC
     5474

  == Outdated reference: draft-ietf-ipfix-reducing-redundancy has been
     published as RFC 5473

  == Outdated reference: A later version (-01) exists of
     draft-stewart-tsvwg-sctpstrrst-00

     Summary: 1 error (**), 8 warnings (==), 0 comments (--)

E2. PR-SCTP is not expanded at first occurrence in the Abstract 

E3. I suggest to change the sentence in the IANA considerations as
follows: According to the process defined in RFC 5202 IANA will allocate
the dataRecordsRelability Information element defined in Section 4.2

---

From: Benoit Claise <[email-masked]>
Date: Tue, 16 Jun 2009 09:48:04 +0200

Dan,

See this email:

    -------- Original Message -------- 

    Subject: 	Re: [Tsvwg] WG adoption of draft-stewart-tsvwg-sctpstrrst
    Date: 	Mon, 27 Apr 2009 16:28:41 -0400
    From: 	Lars Eggert <[email-masked]>
    To: 	tsvwg <[email-masked]>
    CC: 	[email-masked]
    References: 	<[email-masked]>

    The consensus from SF has been confirmed. Authors, please submit the  
    next version of this document as draft-ietf-tsvwg-sctp-strrst-00.

    Lars

    On 2009-4-8, at 11:12, Eggert Lars (Nokia-NRC/Espoo) wrote:

    > Hi,
    >
    > during the WG meeting in SF, there was consensus to take on draft- 
    > stewart-tsvwg-sctpstrrst as a WG item in TSVWG. As always, we'd like  
    > to confirm this result on the list. If you disagree with this  
    > consensus decision, please speak up by April 15.
    >
    > Thanks,
    > Lars

However, draft-stewart-tsvwg-sctpstrrst has not been posted yet

Some background information from 
http://www.ietf.org/proceedings/08nov/minutes/ipfix.txt

    Dan (AD): 
    This draft cannot be a normative reference as long as it is
    not adopted by a the TSVWG. Suggestion: describe the mechanism in the 
    normative part of the text and add an informative reference to the 
    SCTP-RESET document. Once the document is included in the Transport WG 
    charter it can be used as a normative reference. 

I propose that we keep our plan, without waiting for a dependency on the 
(future) TSV WG item.
Are we still in sync?

Regards, Benoit.
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 16 Jun 2009 10:02:03 +0200

We can keep the plan. As it is an informational reference it will not be
a blocking issue. . 
 
Dan

________________________________

	From: Benoit Claise [mailto:[email-masked]] 
	Sent: Tuesday, June 16, 2009 10:48 AM
	To: Romascanu, Dan (Dan)
	Cc: Benoit Claise; Andrew Johnson; Paul Aitken; Gerhard Muenz;
[email-masked]; [email-masked]
	Subject: Re: [IPFIX] AD Review of
draft-ietf-ipfix-export-per-sctp-stream-02 -> reference

	Dan,
	
	See this email:

		-------- Original Message -------- 

Subject: 	Re: [Tsvwg] WG adoption of
draft-stewart-tsvwg-sctpstrrst	
Date: 	Mon, 27 Apr 2009 16:28:41 -0400	
From: 	Lars Eggert <[email-masked]>
<mailto:[email-masked]> 	
To: 	tsvwg <[email-masked]> <mailto:[email-masked]> 	
CC: 	[email-masked]	
References: 	<[email-masked]>
<mailto:[email-masked]> 	

		The consensus from SF has been confirmed. Authors,
please submit the  
		next version of this document as
draft-ietf-tsvwg-sctp-strrst-00.
		
		Lars
		
		On 2009-4-8, at 11:12, Eggert Lars (Nokia-NRC/Espoo)

	

		Dan (AD): 
		This draft cannot be a normative reference as long as it
is
		not adopted by a the TSVWG. Suggestion: describe the
mechanism in the 
		normative part of the text and add an informative
reference to the 
		SCTP-RESET document. Once the document is included in
the Transport WG 
		charter it can be used as a normative reference. 

	I propose that we keep our plan, without waiting for a
dependency on the (future) TSV WG item.
	Are we still in sync?
	
	Regards, Benoit.

		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. 

		E1. idnits complains about a number of IPR boilerplate
issues and
		obsolete references issues: 

		  Checking boilerplate required by RFC 5378 and the IETF
Trust (see
		  http://trustee.ietf.org/license-info):

		  ** You're using the IETF Trust Provisions Section 6.b
License Notice
		from
		     10 Nov 2008 rather than the newer Notice from 12
Feb 2009, which is
		     required now.  (See
http://trustee.ietf.org/license-info/)

		
		     No issues found here.
		
		  Checking nits according to
http://www.ietf.org/ID-Checklist.html:

		     No issues found here.
		
		  Miscellaneous warnings:

		  == The document seems to lack a disclaimer for
pre-RFC5378 work, but
		was
		     first submitted before 10 November 2008.  Should
you add the
		disclaimer?
		     (See the Legal Provisions document at
		     http://trustee.ietf.org/license-info for more
information.). 
		
		     trust-12-feb-2009 Section 6.c.iii text:
		     "This document may contain material from IETF
Documents or IETF
		      Contributions published or made publicly available
before November
		      10, 2008.  The person(s) controlling the copyright
in some of this
		      material may not have granted the IETF Trust the
right to allow
		      modifications of such material outside the IETF
Standards Process.
		
		      Without obtaining an adequate license from the
person(s)
		      controlling the copyright in such materials, this
document may not
		      be modified outside the IETF Standards Process,
and derivative
		      works of it may not be created outside the IETF
Standards Process,
		      except to format it for publication as an RFC or
to translate it
		      into languages other than English."

		
		  == Outdated reference: draft-ietf-psamp-sample-tech
has been published
		as
		     RFC 5475
		
		  == Outdated reference: draft-ietf-ipfix-architecture
has been
		published as
		     RFC 5470
		
		  == Outdated reference: draft-ietf-ipfix-as has been
published as RFC
		5472
		
		  == Outdated reference: draft-ietf-psamp-protocol has
been published as
		RFC
		     5476
		
		  == Outdated reference: draft-ietf-psamp-framework has
been published
		as RFC
		     5474
		
		  == Outdated reference:
draft-ietf-ipfix-reducing-redundancy has been
		     published as RFC 5473

		     Summary: 1 error (**), 8 warnings (==), 0 comments
(--)
		
		E2. PR-SCTP is not expanded at first occurrence in the
Abstract 
		
		E3. I suggest to change the sentence in the IANA
considerations as
		follows: According to the process defined in RFC 5202
IANA will allocate
		the dataRecordsRelability Information element defined in
Section 4.2

---

From: Benoit Claise <[email-masked]>
Date: Tue, 16 Jun 2009 22:51:56 +0200

Dan,
> implementation experience is available I would suggest that we record
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.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 17 Jun 2009 12:24:04 +0200

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? 

Thanks and Regards,

Dan

> -----Original Message-----
> Sent: Tuesday, June 16, 2009 11:52 PM
> To: Romascanu, Dan (Dan)
> Cc: IETF IPFIX Working Group; Randall Stewart; Peter Lei 
> (peterlei); Michael Tuexen
> draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on 
> performance and capacity
> 
> Dan,
> special comments 
> > or concerns I will send it to IETF Last Call by tomorrow.
> >
> > capacity of the reporting and collecting processes. Should 
> we expect 
> > any considerable impact on performance and/or capacity? If any 
> * 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:
> - It is more lightweight to set up additional streams 
> compared to setting up a new association.
> * If the question is about the throughput that could be 
> impaired by processing overhead and message overhead.
> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Jun 2009 13:07:18 +0200

> in order to understand the effects. 

The Security Considerations section of RFC 5101 suggests that IPFIX
favours DTLS for SCTP instead of TLS for SCTP. I must admit that I
have no clue what the state of the art currently is in defining DTLS
usage for SCTP since I am not following the TSVWG. However, there is a
significant difference in terms of overhead between having security on
a per stream basis or having security on a per association basis.
Perhaps this should be considered somewhere in the document if we
like to discuss overhead.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 17 Jun 2009 13:12:54 +0200

Good observation, I believe that this aspect needs to be investigated. 

Dan

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Wednesday, June 17, 2009 2:07 PM
> To: Romascanu, Dan (Dan)
> Cc: Benoit Claise; Peter Lei (peterlei); Michael Tuexen; IETF 
> IPFIX Working Group
> Subject: Re: [IPFIX] AD Review 
> ofdraft-ietf-ipfix-export-per-sctp-stream-02 -> impact on 
> performanceand capacity
> 
> > 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.
> 
> The Security Considerations section of RFC 5101 suggests that 
> IPFIX favours DTLS for SCTP instead of TLS for SCTP. I must 
> admit that I have no clue what the state of the art currently 
> is in defining DTLS usage for SCTP since I am not following 
> the TSVWG. However, there is a significant difference in 
> terms of overhead between having security on a per stream 
> basis or having security on a per association basis.
> Perhaps this should be considered somewhere in the document 
> if we like to discuss overhead.
> 
> /js
> 
> --

---

From: Gerhard Muenz <[email-masked]>
Date: Wed, 17 Jun 2009 13:54:07 +0200

As far as I know, DTLS parameters are negotiated per SCTP association,
not per stream, according to the current state of standardization.

Regards,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Department of Informatics
Technische Universität München
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: [email-masked]    WWW: http://www.net.in.tum.de/~muenz

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 17 Jun 2009 08:01:27 -0700

On Jun 17, 2009, at 4:07 AM, Juergen Schoenwaelder wrote:

>> reading
Since IPFIX uses PR-SCTP you can not use TLS/SCTP since it
does not work with PR-SCTP.

One should not use TLS/SCTP, since I'm not aware of any implementation
of it and you really can not implement it in OpenSSL without
a larger change of the infrastructure.
We do have an implementation of DTLS/SCTP in OpenSSL, so it
* supports SCTP including PR-SCTP and unordered chunks
* is actually implementable.

Best regards
Michael

---

From: Benoit Claise <[email-masked]>
Date: Sat, 20 Jun 2009 01:57:24 +0200

Dan
> 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.
>>> Please consider the comments below together with the other 
>>>       
>> IETF Last 
>>     
>>> implementation experience is available I would suggest that 
>>>       
>> we record 
>>     
>>> it.
>>>   
>>>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 21 Jun 2009 14:21:25 +0200

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

> Sent: Saturday, June 20, 2009 2:57 AM
> To: Romascanu, Dan (Dan)
> 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 
> 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 
> performance 
> >> and capacity
> >> * 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:
> impaired by 
> performance 
> >> of the SCTP socket. I could imagine that a lot of state 
> information 
> >> must be stored.
> >> 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.
> >>

---

From: Benoit Claise <[email-masked]>
Date: Sun, 21 Jun 2009 14:31:42 +0200

Dan,

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

Do you want a quick updated version?

Regards, Benoit

>> (peterlei); 
>>>> Michael Tuexen
>>>> draft-ietf-ipfix-export-per-sctp-stream-02, here are the 
>>>>         
>> conclusions:
>>     
>> capacity" in 
>>>> - With respect of message overhead, we can say that the 
>>>>         
>> fact that we 
>>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 21 Jun 2009 14:42:02 +0200

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:[email-masked]] 
	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,

	
	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. 

		Dan

			-----Original Message-----
			From: Benoit Claise [mailto:[email-masked]] 
			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.

			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:[email-masked]]
				Sent: Tuesday, June 16, 2009 11:52 PM
				To: Romascanu, Dan (Dan)
				Cc: IETF IPFIX Working Group; Randall
Stewart; Peter Lei 

			(peterlei); 

				Michael Tuexen

			performance 

				and capacity
				
				Dan,

			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 

			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.

				Regards, Benoit.