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

From: Jon Berger <[email-masked]>
Date: Mon, 26 Mar 2001 15:41:53 +0100

The cost of unused streams is only zero bytes in the (current incarnation of
the ) reference implementation.  
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
fine, assuming that they are zero cost is not.

Jon

-----Original Message-----
From: Randall R. Stewart [mailto:[email-masked]]
Sent: 26 March 2001 15:27
To: Qiaobing Xie
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Tsvwg] RE: FW: I-D
ACTION:draft-leung-sigtran-stream-sctp-00.txt

Qiaobing:

The current reference implementation uses 4 bytes for an
inbound stream and 4 bytes for an outbound stream. I am 
planning however to reduce this even further so that un-used
streams use NO bytes...

So the cost of un-used streams is '0' bytes of resources.

R

Qiaobing Xie wrote:
> 
> Brian,
> 
> "Brian F. G. Bidulock" wrote:
> >
> > Qiaobing,
> >
> > In implementation, each stream consumes resources other than just it's
> > stream number.  64k is the range of the stream number, but a practical
> > limit may exist well below 64k on an implementation.
> 
> The resource for an idle stream is really small. I remember in the
> earlier versions of the ref. implementation an idle stream consumes less
> than 100 bytes of memory. When you choose an implementation, it's always
> part of the system engineering to make sure you have the desired stream
> capability.
> 
> >
> > Recharacterizing the stream can recover or reuse resources associated
> > with the previous characterization of the stream.
> 
> This can be done if we allow dynamic adding and deleting of streams. I
> think that is a better solution.
> 
> > Otherwise, why not just start with 64k streams inbound and 64k streams
> > outbound with each association?
> 
> That sounds like an irresponsible way of doing system engineering :-)
> 
> >
> > On Thu, 15 Mar 2001, Qiaobing Xie wrote:
> >
> > [snip]
> > >
> > > Why not simply set up a pair of streams (one reliable and the other
> > > unreliable) for this particular session? You can have up to 64k
streams
> > > for each association.
> > >
> > [snip]
> >
> > --
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/tsvwg

-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)

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

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

---

From: "Randall R. Stewart" <[email-masked]>
Date: Mon, 26 Mar 2001 10:15:19 -0600

Jon:

> the ) reference implementation.

No in the current they are 4 NOT 0...

> 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