Subject: RE: SCCP

From: [email-masked]
Date: Thu, 12 Oct 2000 10:08:40 +0300

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.

Regards

Dirk
---------------------------
Dirk Trossen
Research Engineer
Nokia Research
Heltorfer Str. 21
D-40472 Duesseldorf
Tel.: +49 (211) 9412 3495
mob.: +49 (173) 5452420
Fax : +49 (211) 9412 3329
---------------------------

> -----Original Message-----
> From: EXT Carsten Bormann [mailto:[email-masked]]
> Sent: Wednesday, October 11, 2000 8:03 PM
> To: Gonzalo Camarillo; mmusic
> Subject: Re: SCCP
> 
> 
> Christoph Reichert writes:
> > as far as I know, there was no further development of SCCP since I
> > stopped working on it in 1997.
> 
> Actually, there is renewed interest, and we know of at least one
> person working on a followup version.  I'll leave it to him to make
> that work known to this group when he decides to do so.
> 
> > Although I believe the services SCCP provides are still those needed
> > for more controlled sessions (membership-, application-, 
> floor control,
> > capability exchange), I discourage from following the 
> approach taken by
> > SCCP.
> > 
> > The biggest disadvantage is that it depends heavily on a 
> reliable, totally
> > ordered N to N multicast transport. Such a thing is currently "not
> > on the radar", and unlikly to be scalable anyway.
> >
> > If and when more "tighly controlled" sessions should scale 
> up to some
> > hundreds or even thousands of members, and ALF based approach like
> > those taken in the LBNL whiteboard (SRM) or UCL NTE should be taken.
> 
> In the version of SCCP we actually implemented, we used that transport
> because we had it available to us (separation of concern).  Old hands
> of this WG remember that there were earlier attempts on the more
> politically correct peer-to-peer basis (agreement protocol, anyone?),
> which unfortunately never really worked out.  I continue to believe
> the role-based approach of SCCP (use a coordinator for consistency, a
> receptionist for generating refreshes, etc.) is exactly the right way
> to do this.  The transport below that doesn't matter too much (we
> would be using NORM these days, which would mean moving up the
> coordinator function to SCCP).  SSM maybe changes the picture to make
> the coordinator role even more appealing...
> 
> > I do not know the reason why SCCP is still mentioned on the 
> MMUSIC charter.
> 
> Wild guess: Because it's still needed.
> 
> Gruesse, Carsten
>

---

From: Christoph Reichert <[email-masked]>
Date: Thu, 12 Oct 2000 11:33:29 +0200

> 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