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

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 26 Mar 2001 07:41:35 -0800

Hi Randall,

On the SIP working group, discussion is ensuing for the transport of SIP
over SCTP. They are suggesting that SIP is able to use any arbitrary stream
for sending data. That's right any stream. I have been trying to convince
them that this is a bad idea but it also highlights the question, what is an
unused stream if you can arbitrarily receive data on any stream? [according
to this recommendation] I think it would worthwhile if some more SCTP
knowledgeable people weighed into this discussion.

Cheers,

Robert.

-----Original Message-----
From:	Randall R. Stewart [mailto:[email-masked]]
Sent:	Monday, March 26, 2001 4:27 PM
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

---

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

> "Fairlie-Cuninghame, Robert" wrote:
> 
> Hi Randall,
> 
> On the SIP working group, discussion is ensuing for the transport of
> SIP over SCTP. They are suggesting that SIP is able to use any
> arbitrary stream for sending data. That's right any stream. I have
> been trying to convince them that this is a bad idea but it also
> highlights the question, what is an unused stream if you can
> arbitrarily receive data on any stream? [according to this
> recommendation] I think it would worthwhile if some more SCTP

How an application wishes to use streams is up to it... I think
any unused stream COULD be used ... if you have it already as
part of your association... in other words.. 

If I INIT---(MIS=100,OS=100)---------------->

then any stream at any time 0-99 I can send on
HOWEVER I can't send on stream 102 since it is not
part of the association.

I am not sure how this is a bad idea... could you clearify
your concern? Now obviously the two applications ends need
to understand why they are getting data on the stream.. if
your concern is that receiving data on stream 98 out of the
blue (so to speak) will be confusing to the upper level application
and that the application needs to negotiate the use of a
stream... it is probably a correct concern... The application
obviously must know what to do with the data and if there is
a chance it won't then some sort of upfront negotiation mechanism
should be put in to the application ...

I don't see adding a dynamic stream open/close is a good thing 
though the two discussions are orthongal from each other..

R