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

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 2 Apr 2001 04:43:52 -0700

Hi all,

I think we can all see that there may be times when adding or changing a
stream may be useful but according to a number of knowledgeable people, the
on-the-fly change is very messy and ugly. 

How about another approach? Is it possible to re-establish/re-start a
session without interruption to traffic on streams that are unaffected? This
would be the best of both worlds - no extra mechanism is required but
desired functionality is obtained. What problems can people see from an
implementation point of view ?

Cheers,

Robert.

-----Original Message-----
From:	Qiaobing Xie [mailto:[email-masked]]
Sent:	Wednesday, March 28, 2001 12:32 AM
To:	[email-masked]
Cc:	[email-masked]; [email-masked];
[email-masked]
Subject:	Re: [Tsvwg] RE: FW: I-D
ACTION:draft-leung-sigtran-stream-sctp-00.txt

[email-masked] wrote:
...snip...
> 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?

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.

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

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

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

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

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

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