Subject: RE: [Tsvwg] RE: SIP over SCTP [Was: stream-sctp-00.txt]

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 26 Mar 2001 09:02:25 -0800

Hi Randall,

Sorry yes, the stream add/delete is an entirely orthogonal issue.

The suggestion is that the SIP application can without negotiation send on
any stream in the association and the receiving SIP application must treat
any packet on the association equally. It is my impression that the streams
are merely being used to provide reliable ordering between different
call-leg transactions. The application cannot determine on which stream a
packet will arrive out-of-the-blue.

Admittedly, many of the reasons I don't like this idea are related to SIP
rather than SCTP, for instance, this does not allow the application to use a
portion of the streams for some other purposes/other protocols (also
controlled by the application). However, I do think that this sort of
arbitrary send/receive approach enforces certain undesirable application and
transport API properties (ie, every data chunk is an out-of-the-blue
packet).

It's not a technical impossible solution but I still think it is not a good
solution. Possible alternatives for SIP would be to use a single unordered
reliable stream or to add sctp stream specification to the SIP URL (such
that both applications know where to expect messages). Both have their
merits and drawbacks.

Cheers,

Robert.

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

> "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
> knowledgeable people weighed into this discussion.
> 

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

> 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

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

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]