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

From: [email-masked]
Date: Mon, 26 Mar 2001 18:44:00 -0600

From: ext Randall R. Stewart [mailto:[email-masked]]

> 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.

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?

BR,
Ka-Cheong Leung
NRC (Dallas)
Nokia Inc.

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

---

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

> 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

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

---

From: Shyamal Prasad <[email-masked]>
Date: 27 Mar 2001 09:29:32 -0600

"KaCheong" == KaCheong Leung <[email-masked]> writes:

    KaCheong> From: ext Randall R. Stewart
    KaCheong> [mailto:[email-masked]]

    >> 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.

    KaCheong> May you tell me why "whole add/delete of streams "on the
    KaCheong> fly" is MESSY and very ugly"?  Do you have any technical
    KaCheong> points to support this argument?  Note that the idea of
    KaCheong> stream addition/deletion in SCTP is similar to that for
    KaCheong> IP addition/deletion. 

Actually, they are not. In fact, I would suggest that some one show
what the benefits of adding/deleting streams on the fly are with some
REAL applications.

Streams are a way of getting around head of line blocking for
applications that want to do so. Each stream can act as one ordering
domain. That is all they are - there is *no* other feature that
streams provide. In particular, all the streams share the same
rwnd. As many people have already said/complained: one stream can
actually block all the others. People seem to think that streams add
capacity or something cool to a SCTP association - they do not!

It is convenient to use streams as a multiplex at the application
layer. It is easy to argue that once you use streams as a multiplex,
you want to be able to add/delete streams on the fly. It is also a
very convincing line of reasoning, but the basis for it might be
flawed.

We need to think carefully about why we want to use streams as a
application level multiplex, and why those applications cannot
allocate a large number of streams to start with. Why, say, 32 streams
are not enough for an application I would love to know? And why would
the application want to change the number? To what advantage? To say
that at "telecom application" wants to add a few streams with no
downtime is no good, we need to show that the telecom application
gains something from doing so (i.e. other than getting around bad
design ;-). Saying that a user in a conference with 1000 streams needs
to add another one is in the same boat - what happens when you use all
16,384 streams? And how much rwnd were you sharing among those 1000
streams, and what did it buy you?

Cheers!
Shyamal

PS: It's been months since I've worked on any SCTP implementation, so
if I got something wrong, go ahead, flame me and I'll take it ;-)