Subject: Re: Confctrl at March IETF

From: schooler
Date: Thu, 4 Feb 93 14:22:27 PST

Hi,

>From: Fengmin Gong <[email-masked]>:
>
>[email-masked] wrote in a previous message:
>>
>>I'm just getting organized for the March IETF in Columbus, and would
>>like some input.
>>
>>I've scheduled one session for Tuesday morning and am having trouble
>>scheduling the second session.  Please let me know if a Thursday
>>morning session would work for you (that is of course if you are
>>planning to attend IETF).
>>
>
>According to the agenda sent out by Megan on Monday, there is
>already a second session scheduled on Wednesday morning.

Yes, but the schedule continues to get shuffled due to
conflicts with other sessions; we are still sorting this out.
Both sessions are only tentatively scheduled at this point.
I'm just trying to get a feel for who will still be around on Thursday,
if we move one of the sessions there.

>>The first session will be used for presentations about existing
>>conference control schemes.  Thus, I am interested in identifying
>>projects that have been influential or seminal in this area.  Please
>>forward me any ideas you might have, otherwise you will end up with my
>>own biased opinions :-) 
>
>Good idea.  I also feel that these presentations should focus on the
>functionalities (or services) provided by the respective systems. The
>reason is that we need to have a better understanding of the services
>provided by existing systems and then define a set of general desirable
>services, before we can do a good job on developing the conference ctrl
>framework/protocols.  

That is exactly the point of the presentations -- to figure out the set 
of functions or services the various systems consider (i) essential, 
(ii) useful but not central, or (iii) wishlist extensions.  It is likely
that after hearing about several different systems, we will have a better
sense of the general desirable services, as well as some of the
broader issues like operating environment, complexity, overall architecture, 
tradeoffs, assumptions, etc. 

>>The second confctrl session will be for discussion of a strawman
>>framework/protocol, hopefully based on or extended by feedback from
>>the first session.  
>
>Do you have some one that will create the first strawman?  

I was thinking that a strawman framework/protocol might be a result of
the first session, since we will have had a number of different 
reference points to compare and contrast.  However, between now and
the IETF, we can certainly brainstorm about it (the strawman,
as well as a strategy for making progress) via email.

As a guideline for individuals who will be presenting information 
about their confctrl experiences, I would like us to come
up with a template of questions that would help define the strawman.
For instance, a small number of leading questions that we could ask 
designers and implementors to get at the key issues behind conference control.

>I have compiled
>a list of desirable conferencing services that can complement the spectrum
>capabilities and session types from the last BOF.

By all means, let's hear about them (i.e., post a message). 

Eve

---

From: Fengmin Gong <[email-masked]>
Date: Fri, 5 Feb 1993 15:56:20 -0500 (EST)

Hi Eve,

Following up to our earlier discussion, here is a list of conference
services with some justification and discussion of related issues that I
have compiled. Let's have more discussions on this. 

Fengmin

----
The list is ordered so that the most essential services (i.e., from my 
own perspective) appear first:

o Setup, conferencing, and teardown of a point-to-point
  conference: This basic service will require: the setup of a simple
  point-to-point connection in the underlying network with performance
  guarantees, negotiation between two sites to agree on a common capability,
  transport of audio and video streams during conferencing, and termination
  of the conference session and release of all related resources. 

o Conference-room based conference and workstation based
  conference: While workstation based conferencing provides convenience by
  allowing people to participate in a conference at their own desks,
  conference-room based video conferencing can easily 
  accommodate multiple participants at each site and should prove to be
  efficient for many conferences.

o Multipoint conferences with different styles: Many remote conferences
  in practice involve participants from more than two sites.  
  There three major styles for multipoint conferencing (i.e., three points
  on the continuum identified in the last BOF) that have very different
  connection and session control requirements:

  * Brainstorming session where each participants are free to talk (with
    due courtesy, of course) and will be heard by all others.  Audio
    mixing and constant video presence of all participants to all others is
    required.  A many-to-many connection is required of the underlying network.
  * Organized presentation with questions.  In this style, a
    one-to-many connection with floating source locations is required.
    However, audio mixing and constant video presence of all participants to
    all others may not necessary.
  * Broadcast and entertainment video distribution.  Only a static
    one-to-many connection is required to support such conferences.

In addition to the connection and session control requirements, multipoint
conferencing also presents challenging problems in the areas of echo
cancellation, audio mixing, audio level calibration and
dynamic adjustment, and switching and display of multiple video streams.

o Dynamic session control: The ability to add and delete participants
  to and from an existing conference is highly desirable.  Such change of
  configuration may require modification to the underlying network connections.

o Conference directory:  A conference directory service that supports
  conference registration, announcement, and query will be very useful.  This
  directory will contain at least the following information:

  * Title and description of the conference.
  * Multicast address (if it is an open conference).
  * Start and end, date and time for a conference.
  * Participants list (if it is an open conference).
  * Audio coding schemes, protocols, and {\sc qos} requirements.
  * Video coding schemes, protocols, and {\sc qos} requirements.

o Automatic conference scheduling: Automatic scheduling of
  conferences will be very important when packet audio and video conferencing
  becomes ubiquitous.  The scheduling ability coupled with resource
  reservation mechanisms will allow efficient planning of network resources
  on a more global scale and thus provide different types of conference
  services at various cost, much like the long distance telephone services
  today (e.g., day time vs.\ evening and weekday vs.\ weekend).

o Automatic conference recording: Another useful service
  is the ability to record conference sessions as a multimedia
  document/proceeding. Such documents along with technical papers (i.e., in
  electronic form) can then be archived and accessed by a
  larger community than that of the conference participants.