Subject: RE: SCCP

From: [email-masked]
Date: Thu, 12 Oct 2000 12:55:28 +0300

Hi,

there was some kind of misunderstanding concerning the term 'group'.
Definitely, MMUSIC is the group to discuss SCCP and related approaches.
I meant to say that supporting thousands of participants is not usually
within the scope of tightly-coupled conferences.

Concerning the term 'tightly-coupled', you're right that there is
some kind of misunderstanding. It does not imply that reliable
transport or even unicast transport is a must to be used, e.g. as in
the H.323.

Regards

Dirk

> -----Original Message-----
> From: EXT Christoph Reichert [mailto:[email-masked]]
> Sent: Thursday, October 12, 2000 11:33 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: SCCP
> 
> 
> On Thu, Oct 12, 2000 at 10:08:40AM +0300, 
> [email-masked] wrote:
> > Hi all,
> > 
> > Let me introduce myself as at least one person working on 
> the followup 
> > version of SCCP (I suppose Carsten had my name in mind when 
> writing this).
> > 
> > The current status is somewhat of becoming stable. However, there is
> > no exact date when to provide this as a renewed version to the
> > group since I'm currently busy with some other business (moving to
> > another country). However, I'll keep the working group updated
> > when there's a draft to discuss.
> > 
> > Concerning the question of mentioning SCCP in the charter 
> (and also in
> > the current conferencing architecture draft), I fully agree with
> > Carsten's comment: It's still needed. 
> > 
> > Regarding Christoph's comment about using 'tightly-coupled' 
> approaches
> > for several hundreds or even thousands of users, I don't think that
> > this is the group of interest when having applications for this
> > in mind. Nobody would use H.323 for town-meetings of 
> several hundreds
> > of people. However, it might be interesting to propose a 
> version of SCCP
> > which scales to some kind of number; the higher, the 
> better. For that,
> > the services have to be designed to scale to some extent which is 
> > basically the ongoing work concerning SCCP.
> 
> Agreed, nobody would use H.323 for large meetings, eg. IETF 
> plenary sessions.
> But this is simply because H.323 does not scale.
> 
> WB has been tested with thousands, and NTE with hundreds of members.
> If this is possible for data applications, then it should 
> also be possible
> for control applications. And RTP based applications scale anyway.
> So, if every component scales, the whole system scales.
> 
> Why is MMUSIC not the group for such things ? IETF WG meetings are
> large sessions, and the plenaries are even larger. It seems natural
> to me to make things scale at least to this order because there is at
> least one existing need: our own.
> 
> I believe there is still a great misunderstanding concerning the term
> "tighly-coupled" sessions. IMHO, "tighly-coupled" sessions 
> have nothing
> to do with the transport beeing used. "Tightly coupled" 
> sessions simply
> means more exchange of control information to make user's life easier
> and to allow more interaction than in a "crowd around an attraction".
> It is still believed that for "more control" in sessions, a reliable
> transport layer is needed (I believed it, too). As NTE and WB 
> demonstrate, 
> there are better ways.
> 
> Anyway, I am curiuos about your SCCP extensions.
> 
> cheers, chris
>

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Thu, 12 Oct 2000 13:14:22 +0200

> transport or even unicast transport is a must to be used, e.g. as in

Of course tightly-coupled implies a reliability protocol, otherwise you have
little assurance that the state of the participants converges.  Whether
reliability is a transport function or a property of the application
protocol, and whether it is achived by saturation (endless repetition),
forward error correction, or retransmissions, does not really make a
difference (and I think this is what you are addressing).

Of course, there are various aspects that together could be called tightly
coupled.  State convergence is one.  Another requirement in many conferences
is the execution of a common policy with respect to member requirements and
requests -- this is much harder to scale.

Gruesse, Carsten

---

From: Christoph Reichert <[email-masked]>
Date: Thu, 12 Oct 2000 17:01:55 +0200

> difference (and I think this is what you are addressing).

There must be at least enough "application redundancy" to achieve
semi-reliability. However, this does not imply per message reliability
(as shown in the NTE implementation).

> coupled.  State convergence is one.  Another requirement in many conferences

Yes, and this problem is harder to solve than reliability, and
reliability and total ordering an all that stuff alone is not enough to
achieve consistency. So the question is if there are other mechanisms
to achieve state convergence.

cheers, chris