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

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.

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

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 27 Mar 2001 16:32:16 -0600

[email-masked] wrote:
...snip...
> to support THIS) if it cannot handle such WORSE CASE scenarios?

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.

> single transmission trunk, or stream multiplexing in SCTP here).

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

> systems can then be removed.  We, engineers, may not even have our jobs

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. 

-Qiaobing