Subject: FW: I-D ACTION:draft-leung-sigtran-stream-sctp-00.txt

From: [email-masked]
Date: Wed, 14 Mar 2001 11:36:42 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2001 12:49 PM
> To: IETF-Announce; @[email-masked]
> Subject: I-D ACTION:draft-leung-sigtran-stream-sctp-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: SCTP Stream Function Extensions
> 	Author(s)	: K. Leung
> 	Filename	: draft-leung-sigtran-stream-sctp-00.txt
> 	Pages		: 10
> 	Date		: 05-Mar-01
> 	
> This document describes two stream function extensions to SCTP
> (Stream Transmission Control Protocol) [SCTP].  These extensions are
> to allow dynamic modifications of stream status when U-SCTP
> (Unreliable Extension to SCTP) [USCTP] is activated and on demand
> insertion/deletion of streams within a SCTP association.  These
> extensions will provide a better support of multimedia applications
> since they allow users to set and modify communication options, say
> the choices of transport and reliability requirements, on the fly.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-leung-sigtran-stream-sctp-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-leung-sigtran-stream-sctp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-leung-sigtran-stream-sctp-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 15 Mar 2001 17:43:29 -0600

> > - Is there really a need for the added complexity of changing from a
> > reliable to an unreliable stream, or vice versa ? To me this looks
> ? like an unnecessary complexity that could be more easily solved by
> > deleting the stream, then adding it again.
> 
> It should be better to have a scheme to handle such modification
> as a reliable stream and an unreliable stream are handled differently.
> Besides, it seems always possible to implement a modification by placing
> a delete and then add it back again.  However, it seems to be more
> efficient of simply modifying the stream status (and its related context)
> instead of a two-step delete/add procedure.  What do you think?

Sorry, Cheong, I am not convinced that this mechanism is needed.

First, I don't see why such a mechanism is needed. Can you give me an
example? To make your reliable/unreliable changeover mechanism work,
there will be substantial complexity added to both ends. We need to
justify it first.

Secondly, without adding anything, U-SCTP can already do what you
described. Remember that the user at the sender can set a retransmission
count N to each outbound message. All you need to do is to setup an
unreliable stream, and when you want to use it as unreliable, you simply
set N=0 for each outbound message. For the period for time you want it
to be reliable, you simply set N=100 (or any other high number) on each
out-bound message and this will basically guarantee reliable delivery of
the message.

-Qiaobing

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

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 16 Mar 2001 13:30:22 -0600

comments below...

[email-masked] wrote:
> 
> Attached is my comment.
> 
> > 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.
> 
> Good question!  This can be answered by the fact that many
> applications (like multimedia conferencing applications)
> do not know how many streams (and their types) for sure
> they need when the association is established.  

This is more an argument for the dynamic adding and deleting of streams.
This idea has come up in the sigtran several times. The conclusion from
past sigtran discussion was: since streams are considered cheap
resource, the association can always be setup with the max number of
streams the application will ever need. Therefore, the dynamic adding
and removing of stream was considered a low priority feature. I think
this can be re-discussed if there is enough interest in it.

> The proposed
> set of modifications is a solution to the captioned problem
> whenever a change is needed on the fly of an established
> association.
> 
> > In the contrary I think this is an elegant solution, simple, easy to
> > use, and efficient. The reliability is guaranteed because your SCTP
> > association will fall apart hours (even days) before you can reach the
> > 99th retransmission of the same message.
> 
> Well, first, the validity of your argument depends on the
> pre-set initial time interval.  

Remember RTO.Min is 1 sec. Let's see an example. Assuming you have 5
transport addresses for the peer, the time you will have to take to
reach the 100th retransmission will be roughly 1*5*(2E(20+1)-1) ~= 60
days. If you set you RTO.min to 1 ms, this will still take ~1.45 hour!
If your peer is single-homed, it will then take 1*1*(2E(100+1)-1) secs
to reach the 100th retrans. I don't know how many hundred years is that.

> Second, if an association is
> used as a semi-permanent association between two end-points
> (for signalling or monitoring purposes), its life-span might
> be much longer.  

There will be no life left for the association if the SCTP stack
underneath has determined the peer is unreachable.

> Furthermore, it is possible to construct a
> scenario where a certain "bad luck" packets to be lost during
> the (re-)transmissions whereas an association can still be
> alive (noticed that those association and path retransmission
> counters are re-setted.

This case is so pathological... First if the message is really that "bad
luck", the difference a reliable stream can make for you in this case is
to continue retransmit it after the first 100 retrans. Then where is the
guarantee that another 100 retrans will get it through?!? And what good
will it do to the application for delivering a message more than 60 days
old?!

> Just my 2 cents.
> BR,
> Cheong

---

---

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
> 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.
> 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]
> > > >
> > > [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)

---

---

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

Jon:

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

> fine, assuming that they are zero cost is not.
> 
> Jon
> 
> Sent: 26 March 2001 15:27
> To: Qiaobing Xie
> > > In implementation, each stream consumes resources other than just it's
> > > stream number.  64k is the range of the stream number, but a practical
> > 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
> > This can be done if we allow dynamic adding and deleting of streams. I
> > > Otherwise, why not just start with 64k streams inbound and 64k streams
> > That sounds like an irresponsible way of doing system engineering :-)
> >
> > >

---

---

From: Alex Audu <[email-masked]>
Date: Mon, 26 Mar 2001 14:36:05 -0600 (CST)

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.

Regards,
Alex. 

----original message----

R

---

---

From: Sean McVeigh <[email-masked]>
Date: Mon, 26 Mar 2001 16:30:02 -0500

I'd assume that a loss of signalling wouldn't constitute a loss of
service
since stable calls would remain in service.  Although, I agree that
allocating
the maximum number of streams at setup time would be preferrable to
having
to tear down the association and rebuild it, while buffering outbound
data
waiting for it to come back up (although I'm still not quite sure how
Randall
claims he's going to do it with 0 bits per stream.. if he succeeds in 
recording state using no space I think he has a money maker on his hands
;)

Sean

-- 
Sean McVeigh                                     Software Designer
Alcatel Carrier Internetworking Division   -    Edge Data Networks
Tel 613-784-5367  Fax 613-599-2915  Email [email-masked]
                  All your base are belong to us.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 26 Mar 2001 23:06:03 -0600

Sean,

Recording state for idle streams with zero space is possible.  Active
streams, no.

On Mon, 26 Mar 2001, Sean McVeigh wrote:

> service since stable calls would remain in service.  Although, I agree
> that allocating the maximum number of streams at setup time would be
> preferrable to having to tear down the association and rebuild it,
> while buffering outbound data waiting for it to come back up (although
> I'm still not quite sure how Randall claims he's going to do it with 0
> bits per stream.. if he succeeds in recording state using no space I
> think he has a money maker on his hands ;)
> 
> Sean
> 

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

---

From: "Randall R. Stewart" <[email-masked]>
Date: Tue, 27 Mar 2001 06:59:21 -0600

[email-masked] wrote:
> 
> From: ext Randall R. Stewart [mailto:[email-masked]]
> 
> May you tell me why "whole add/delete of streams "on the fly" is MESSY
> and very ugly"?  Do you have any technical points to support this argument?
> Note that the idea of stream addition/deletion in SCTP is similar to
> that for IP addition/deletion.  The merits/drawbacks of stream
> addition/deletion might apply to the case for IP addition/deletion,
> but I do think that there is a ground to include these concepts to the
> base SCTP defined in RFC 2960.  Don't you agree?
> 

Streams are a lot different than IP addresses and are not
at the same level. An IP address helps me identify the association
and nothing more. Streams within SCTP represent state. Has such
they hold sequence numbers (both what I am sending and what
I next expect), reordering queues, and possibly limits on how
much can be sent to a stream. These are not on the same level.. sorry
I don't by any such argument.

Now as far as how streams are messy... in some of the earlier
versions of SCTP (which you may or may not be aware of) we had
the ability to add and delete streams dynamically. Under the
advice of the IESG and the transport area directorate we removed
this... I don't remember all the reasons (check out the email 
archives if you want to get some perspective on it)...
One of them I am sure is that architectually it is in-elegant. There
were other reasons too but my poor brain just can't remember them all
... it was about the Oslo IETF that we discussed this and I think
I finished ripping it out by the Washington DC IETF...maybe before.

Now I was against this at first. After talking with Lixia and Vern
I was semi-convinced... I then "saw the light" when I went to the
reference implementation (yes I had this coded) and ripped it out.
It was a horrible plague effecting about every module in the
implementation. After ripping it out the reference implementation
lost about 1,000 lines of code. At that point I was even more
conviced it was ugly. 

Especially when one considers how cheap streams are.  There is
no reason that ANY implementation can not minimize the state
kept on a un-used stream. In fact I contend that there is no
reason that any state needs to be kept until the streams are
actually used... this is NOT how the current ref-impl works but
it will soon. Now of course once used they do require a bit
of state but if you are going to use it anyway you are going
to pay the price of that state, reliable or un-reliable. And yes
I know you can free() things but this is not always the case
in the kernel..calloc() and free() work just a bit different
when you are down under :)

I see NO advantage to your proposal. If you don't know 
how many streams you need allocate 32k unreliable and 32k reliable.
Then on the fly use the ones you want. In a good implementation
allocating 64k streams should cost you no more than what you
use..

R

> Ka-Cheong Leung
> NRC (Dallas)
> Nokia Inc.

---

---

From: "Randall R. Stewart" <[email-masked]>
Date: Tue, 27 Mar 2001 07:14:32 -0600

> recording state using no space I think he has a money maker on his hands

That would be quite a cash cow, now would it not? Sorry to say
you missed my point. 

1) I know a-priori that a stream will start with Sequence number 0 when
   I send.
2) I know a-priori that a new stram will start with Sequence number 0
   when I receive.

So if I want to change the current ref-impl from its .. staticly
allocate N streams in and O streams out... I instead place these
values as limits... anytime I get a stream sequence number I look
in a hash table (after validating agains N/O) and see if I have
a stream state structure. If not I allocate it and place it
in the hash table... if so I use this stucture.

Tada... no cost for un-allocated streams until you use them.

R

> You are currently subscribed to sigtran as: [email-masked]

---