Subject: Conference Services (DSI View)

From: Chip Elliott <[email-masked]>
Date: Fri, 5 Feb 93 16:48:25 EST

Hi Eve and Fengmin and everyone,

Now I'll throw out my 2 cents' worth on conference service issues.
I'm approaching these questions as one who's just finishing up an
implementation designed for real customers (the DSI video sites).
This has both benefits and drawbacks -- I know exactly what
services I must provide and hence have very clear ideas; but on
the other hand, they may be too limited.

I toss them in because I think the design space contemplated in
this mailing list is rather different from the one I've been
working in.

Eve is quite familiar with DSI video-conferencing, but I'll
sketch it for others who are not.

OVERVIEW of DSI VideoConferencing
---------------------------------
We have about 30-40 sites worldwide with a special internet that
provides multicast and bandwidth reservation. Video sites have
specially prepared conference rooms with PictureTel codecs,
good mikes and speakers, echo cancellation equipment, and
Sun workstations for control. (There's quite a bit more hardware
too but it's not terribly relevant here.) New sites are being
added at the rate of 1 per week.

The network typically supports a few video conferences each
day. These are real working meetings, not technology demonstrations. 
We run the PictureTel codecs at 112kbits/sec with inband audio;
special hardware packetizes the codec data stream. Most conferences
have 2 or 3 sites; 4 is not too uncommon; larger ones are very rare.

Bandwidth reservation is a very important problem since each
codec chews up a fair amount of the network. At present, bandwidth
is centrally administered by people. An automated system seems
infeasible since certain customers are important enough that they
could "bump" others, but the ordering is by no means obvious.

Our Ideas of "Essential" Services
---------------------------------
I'll base this list on Fengmin's to keep some semblence of order here.
Our wishlist has distinctly different priorities than his, however.

o Setup, conferencing, and teardown of BOTH pt-pt and multipoint
  conferences. We absolutely must handle both.

o 2-3 site meetings are most common. But these are NOT "brainstorming";
  they are orderly business meetings.

o Dynamic session control is extremely important. In real meetings,
  some groups arrive 5-10 minutes late, equipment breaks, etc.
  These things must be accomodated. The other groups in a conference
  must not be left twiddling their thumbs; the meeting must start
  minus some participants, in hopes that they will join later.

o Sometimes meetings must be moderated, ie, one site will control
  who everyone looks at. Other times individual sites will choose
  who they see. Both must be accomodated.

o If the technology can support it, there might be some demand
  for larger meetings (eg 10 sites). These would undoubtedly be
  moderated; they might be lecture-type, or they might be
  round robin.

And a few things he didn't mention:

o Quality of Service. It must be, consistently, of near-VCR quality.
  Otherwise the whole system is pointless. Degradation of quality
  is unacceptable.

o Reliability and Robustness. Conferences are important meetings;
  they must continue as best they can in the presence of equipment
  failures, human error, etc. This is extremely high priority.

o Diagnostics. We must be able to track down and eliminate problems.
  (This has some impact on conference control protocol design, in my opinion.)

o Multicast and Bandwidth Reservation. 112kbit/sec n-way media streams
  are simply not feasible without this. And dropped packets are
  definitely a bad thing.

o Address Books. It must be easy to call up other sites.

o Names and titles of participants. We don't support this but
  we should. People sometimes get confused as to who/where they
  are looking, talking to, etc.

Things that are Not Important to Us
-----------------------------------
o Workstation-based videoconferencing. In fact, I think many
  of our users do not know how to use computers. They have
  technicians to do that for them.

o Media negotiation. Sites have relatively homogenous hardware.
  (This seems like the most likely thing to someday become important.)

o Broadcast.

o Conference directories. In fact, these are UNWELCOME. These
  are private meetings.

o Automatic conference scheduling. See above for rational.

o Automatic conference recording. VCRs do this just fine.
  No one has ever requested a recording of the multimedia
  aspect of a conference.

So, now I'll pose a question to you all. Are you designing
a researcher's conferencing system? I would argue that my list
of priorities above is similar those of anyone with real,
paying customers. Are such production-oriented systems
outside the design space you want to consider?

Cheers, and hope to see you at the BOF in Columbus,

-- Chip Elliott		[email-masked]

---

From: Fengmin Gong <[email-masked]>
Date: Mon, 8 Feb 1993 09:58:26 -0500 (EST)

>OVERVIEW of DSI VideoConferencing

I agree that resource reservation is no simple task, but is not
infeasible and we need to address them now.  Of course, if many
people wants to use a shared network for conferencing, there must
be some way rationing the use and charging for bandwidth and "bumping"
privilage may be one way of doing that.

>Our Ideas of "Essential" Services

Well, 2-site meeting is pt-pt and 3-site orderly meeting can be 
considered as a special case for organized presentation style.  I
admit that I was thinking more of the underlying connection session
control requirements when I explicitly listed three styles, rather than
the high level distinctions (e.g., business meeting or a workshop
discussion).
 
>  who they see. Both must be accomodated.

Very good point.

>  failures, human error, etc. This is extremely high priority.

Yes, these items should be explicitly specified as service items.
More appropriately, they should be specified as QOS/Reliability/Robustness
guarantees.

>  (This has some impact on conference control protocol design, in my opinion.)

Yes, this is an essential service to provide.  Although the user for this
service may be different from users (participants) of conferences.

>  are simply not feasible without this. And dropped packets are

This is a requirement implied by multipoint conferencing services.

>  are looking, talking to, etc.

This should be part of a directory service.  I think you probably assumed
that a directory is always a publicly accessible service.  It needs not
that way, particularly for conferences.  You may have items in the
directory that allows only restricted access or you may have private
directories.

>Things that are Not Important to Us

Even if many of you users do not know how to use computers today, some
of them do and I think many more will tomorrow.  There is additional
advantages provided by workstation conferencing capability.  You can
have mixed workstation and conference-room based sites in one conference.

>o Conference directories. In fact, these are UNWELCOME. These

See rationale earlier.

>  No one has ever requested a recording of the multimedia

I will be useful to get some feedback about the usefulness of this
for tomorrow.

>outside the design space you want to consider?

I am personally interested in a system that can serve both
reserchers and business executives.  I don't see fundamental difference
in the functionality requirement between these users.  As long as
resources (e.g., bandwidth) are not as plentiful as we want, there
must be some mechanism for determining who can and when to use the
available resources.  A business user may enjoy more previlage by paying
more, or using his or her dedicated links.  I think a more general set
of services should be identified first; if the technology prevents certain
services from being provided for now, nothing can be done about it.  But
nothing useful should be ruled out at this stage.

>-- Chip Elliott		[email-masked]

Sure,

Fengmin