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

From: [email-masked]
Date: Thu, 15 Mar 2001 18:37:06 -0600

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

Just my 2 cents.

BR,
Cheong

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

---

From: [email-masked]
Date: Fri, 16 Mar 2001 15:28:37 -0600

Hi,

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

Well, this is a solution but it might not be elegant enough.
According to RFC 2960, the SEND/RECEIVER primitives allow users to
specify a stream identifier for data transmission.  This
information is generally used for dispatching data to different
data (media) streams within an association.  If a stream
recharacterization results in a stream deletion and an addition,
(possibly, but not necessarily) a stream id for a CERTAIN
stream might be changed.  As it does involve 2 parties, a
(substantial) delay due to possibly a re-mapping between a
stream id and that for ULP is needed.  This is a downside
towards your suggested approach.

Furthermore, a stream deletion/insertion approach can cause
traffic blockage to an on-going stream, which simply wants
to change its status, as well.

Just my 2 cents.

BR,
Cheong

---

---

From: [email-masked]
Date: Sun, 18 Mar 2001 01:13:57 -0600

My comment below ...

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

Hey, I have forgotten to state my point clear at the time
when I sent the reply.  Your argument here is generally
correct!  What I'd like to say is that we've to pay
attention as it is an "okay" solution to deal with the
problem at the present time, but it might not survive over
time or for extreme cases.  Just in case if RTO can reduce
substantially (but now it is still not possible simply
because of the constraint in speed propagation).

Probably, we'd make a note (pre-condition) w.r.t. such a
specific way of implementation so that it helps whenever
problem arises, since this could be a source of (logical)
bugs.  I'd like to make that note as such apparently handy
but conceptually unclean (well, it depends on case-by-case)
design pitfalls have happened during our previous discussion
before.

Twenty (?) years ago, programmers paid more attention to
the memory usage (or just took a handy way to do programming)
but ignore the effect due to incomplete representation of
the year of a date, a so-called millennium bug (but actually
much more than that) arises.  Indeed, there are much more daily
examples we can find!  I think you do know much more about
what I'd like to address and hope you'd pay attention w.r.t.
the robustness issue of a protocol design, where I weight
it the most important issue (even important than its efficiency).
As a designer as well as a customer, I can barely survive
with a less efficient product but definitely not for a buggy
product!!!

> > Second, if an association is
> > be much longer.  

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

Any relation to my argument?  Take a simple term, what I mean is
that some associations might survive for several days or even
much longer.

> 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?!

Well, this is an extreme cases, but the design cannot prevent a
similar situation to happen, right?  As I mentioned above, your
argument is generally correct PROVIDED the current standard RTO
setting.  In the specification, this is an additional assumption
(since the actual implementation of such reliable transport deviates
with its conceptual behavior) and it should be stated clearly so
that follow-up work can do if needed.

Just my 2 cents.

BR,
Cheong

---

---

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

---

---

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.

---

---

From: [email-masked]
Date: Mon, 26 Mar 2001 18:35:09 -0600

> From: ext Qiaobing Xie [mailto:[email-masked]]
> Sent: 26 March, 2001 5:45 PM

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

> I'd argue that you will be in the same situation if you find that your
> application runs out of memory and you have to shutdown the machine and
> add more memory cards. 

> You can avoid to paint yourself into this corner by a good planning of
> your stream resource and its usage, instead of asking SCTP to cover this
> type of mis-planning or mis-configuration of the system capacity.

Qiaobing:

Sorry, I cannot agree with you anymore.  Suppose you are engaging in
a multimedia conference with 1000 people, each of them can be able to
SELECTIVELY hear others' voices, write their messages, view their pictures,
process some archive multimedia data between a subset of audiences.  Do
you mean that the application has to set up all associations under the
worse case scenario, say 100 streams inbound/outbound per association;
or just DENY the service (ask the guy to upgrade the server unnecessarily
to support THIS) if it cannot handle such WORSE CASE scenarios?

From my viewpoint, one of the major merits for stream status modification
and dynamic stream addition/deletion is to allow the systems to efficiently
use of resources.  Applications may have their on-demand additional requests
rejected because of the lack of system resources, but not the support for
the bare/normal service.  I'd consider this is reasonable, and appropriate
the design trend (just like multiplexing of multiple traffic streams into a
single transmission trunk, or stream multiplexing in SCTP here).

Furthermore, if anything can be well-planned and well-known in advance,
this could save much of our work and lots of control and intelligent 
systems can then be removed.  We, engineers, may not even have our jobs
here!

Just my 2 cents!

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

---

---

From: [email-masked]
Date: Tue, 27 Mar 2001 17:39:17 -0600

-----Original Message-----

> How does adding/deleting streams let you get away from system
> configuration in such a complicated use scenario? How does the
> pre-configuration of the number of steams have anything to do with the
> way you setup all those associations among the 1000 users? Or, are you
> thinking about your worst case as running 1000x1000 AV sessions amongst
> the users over separate streams in just _one_ association? I don't get
> it. Please explain.

Let's consider two scenarios:  one with only pre-configuration at the
start of an association, and one with stream addition/deletion.  In the
first case, an application has to pre-set all 1000 associations, each
with 100 streams set, regardless of whether a particular stream will be
used, and/or how long it will be used.

For the second case, the application needs to set up these associations,
of course.  However, the major difference comes with the fact that each
association may take 1 inbound/outbound stream at the beginning, and
additional streams are added whenever needed.

Moreover, the life-spans of some streams may indeed short, relative to
the life-span of an association.  It is better to relinquish the resources
captured for these streams whenever it is no need to further use of the
streams.  As R pointed out that the maintenance of a set of un-used
streams is cheap, I totally agreed with him up to this point.  However,
once a stream is activated, a stream's state has to be maintained in a
separate manner and it might no longer be cheap.  This is true that if
some applications are operated in a way such that streams are used in
a very short life span and then they might no longer be used later on.
An application that potentially exhibits such behavior is a sort of
n-party multimedia conference application where it supports the transport
of, but not limited to, video, audio, shared white boards, instant
messages, and archival multimedia data.  The memory and other related
requirements will continue to grow with the associations' life spans,
that might simply because the user continues to switch to communicate
with different users, or/and viewing/operating different media/tools.
I hope this part could answer to Shyamal's, R's, and your questions.
If it is not clear, please let me know.

> What do you mean by "not support the normal service"? How do your define
> the difference between your "on-demand additional requests" and "normal
> service"? 

OK, in reality, just like the conventional video conference or the
limitation
of human beings, the number of facilities that are actually related to the
actual
operations, say listening to one's voice, viewing several (a few) videos, of
an
user at any given point in time is rather limited.  I denote this as a sort
of
normal service.  You can define it as another term to avoid confusion if you
wish.  This relates to and probes against the capacity of the system, but
one
trying to do things under the worse case scenario does not.

On-demand additional requests means the requests initiated to change
the current operation mode.  For example, an user originally simply
listen to only the speaker's voice.  Now, he/she wants to view his/her
image.  I consider the latter as the additional requests made by the user,
with respect to the original setting to the application.

> Good engineers know the merits of function partitioning when designing a
> system. To ask the transport protocol to share the burden apparently
> belonging to resource planning and system configuration doesn't make
> good sense to me. In a call processing system for example, when the
> designed call capacity is reached, your call control function will
> reject any new calls way before your hardware box runs out of line cards
> and shoots errors all over the place. 

I agree to you in general for the statements you mentioned.  Just
like the case if the application does not know the maximum number
of streams needed, it always make requests w.r.t. the upper bound
or any system pre-defined configuration parameters (like maximum
number of streams supported by SCTP), this actually falls into the
categories you mentioned!

The proposed stream addition/deletion and stream status modification
does not contribute to the decision making in resource planning and
system configuration.  This only provides interfaces to do these
operations.  It is orthogonal to when and how to invoke such operations,
which are left to the decisions from ULP and/or other resource
management/configuration modules.  

BR,
Cheong

---

---

From: [email-masked]
Date: Tue, 27 Mar 2001 17:44:47 -0600

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

Hum, there is a state (like path status, retransmission counter,
active/inactive, ...) associated with each outgoing IP address.
Thus, I intend to say that both IP addresses and streams have
to maintain states.
 
BR,
CHeong

---

---

From: Lyndon Ong <[email-masked]>
Date: Tue, 27 Mar 2001 11:11:38 -0800

I must say, I tend to agree with this.  It's not clear that we are really adding much useful functionality by adding and deleting streams.  We discussed this when we defined the protocol and decided that it was easy to incorporate more streams when the association was created.  I'd like to see more drawn from experience with the protocol before we go about making too many changes.

Cheers,

Lyndon
--

On 27 Mar 2001 09:29:32 -060   Shyamal Prasad wrote:
>    "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 ;-)
>

Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com

---

---

From: [email-masked]
Date: Thu, 29 Mar 2001 18:42:15 -0600

Supplementary information to what I said!

-----Original Message-----

I agree to you in general for the statements you mentioned.  Just
like the case if the application does not know the maximum number
of streams needed, it always make requests w.r.t. the upper bound
or any system pre-defined configuration parameters (like maximum
number of streams supported by SCTP), this actually falls into the
categories you mentioned!
     ^
     L------------- "To ask the transport protocol to share the burden
			   apparently belonging to system configuration
                     doesn't make good sense"

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

---