Subject: Re: [Tsvwg] RE: FW: I-D ACTION:draft-leung-sigtran-stream-sctp-00.txt

From: Qiaobing Xie <[email-masked]>
Date: Mon, 26 Mar 2001 17:45:26 -0600

Alex Audu wrote:
> 
> Randall
> 
> The alternative to dynamic addition of streams is to bring down the whole
> association and re-establish it with an updated stream count.  For a telecom
> application, that may mean temporary loss of signalling for existing
> connections, and inability to make new connections while the association is
> down because we are adding a new customer, or something like that.  That is a
> loss of service,..and not a very good idea at all.

I'd argue that you will be in the same situation if you find that your
application runs out of memory and you have to shutdown the machine and
add more memory cards. 

You can avoid to paint yourself into this corner by a good planning of
your stream resource and its usage, instead of asking SCTP to cover this
type of mis-planning or mis-configuration of the system capacity.

-Qiaobing
 
> Regards,
> Alex.
> 
> ----original message----
> Jon Berger wrote:
> >
> > The cost of unused streams is only zero bytes in the (current incarnation of
> > the ) reference implementation.
> 
> No in the current they are 4 NOT 0...
> 
> > If you didn't want to be allocating and freeing memory as streams come into
> > and out of use, this is not a good thing to depend on.  I don't think we
> > should be architecting solutions on top of SCTP that rely on a particular
> > implementation for validity.  Assuming streams are relatively lightweight is
> 
> I was attempting to emphasis that they CAN be implemented at
> a cost of 0 bytes... even in kernel land. I.e. they are CHEAP.
> 
> Yes some implementations will always do pre-allocation.
> 
> The whole add/delete of streams "on the fly" is MESSY and very ugly. I
> do not support it. I don't like the idea it complicates thing
> unnecessarily.
> 
> R
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg