Subject: Confctrl BOF at upcoming IETF

From: schooler
Date: Mon, 22 Mar 1993 23:46:51 -0800

At the Washington, D.C. IETF, there was an impromptu meeting of
individuals interested in the session control aspects of an 
Internet remote conferencing architecture.  The group is officially 
scheduled to meet as the Conference Control BOF at the upcoming IETF.
Here is the proposed agenda and draft charter, which we expect to refine 
after discussion within the BOF and within the IESG.  

I welcome your comments and participation.

Eve Schooler
([email-masked])

Agenda for the Conference Control BOF (confctrl)
------------------------------------------------

Tuesday, March 30,	9:30 - 12:00 noon
Wednesday, March 31,	1:30 - 3:30pm 

 1. Agreement on agenda

 2. Brief introduction with an overview of minutes from 
    Washingon, D.C. confctrl meeting

 3. Review of charter and milestones (goals and objectives)

 4. Report on current confctrl bibliography

 5. Presentations of existing confctrl schemes

 6. Synthesis of critical confctrl attributes, functionality,
    requirements

 7. Discussion of architectural assumptions for confctrl
    of Internet teleconferencing.

 8. Identify documents/materials that need to be produced,
    and assign writing tasks.

 9. Other topics???

Proposed Charter
----------------

Charter 
     Conference Control (confctrl)
 
Chair(s):
     Eve Schooler		<[email-masked]>
     ???? 

Applications Area Director(s) 
     Russ Hobby			<[email-masked]>
     Erik Huizer		<[email-masked]>
 
Mailing lists: 
     General Discussion:	[email-masked]
     To Subscribe:      	[email-masked]
     Archive:           	venera.isi.edu:confctrl/confctrl.mail
				[contains minutes from previous IETF]

Description of Working Group:

The demand for Internet packet teleconferencing has arrived.  Yet, an
infrastructure to support the demand is barely in place.  Conference
control is one component of the infrastructure, and may be defined as 
the management and coordination of multiple sessions, and their multiple 
users in multiple media.  The Conference Control Working Group is chartered 
to design a session layer protocol to perform these functions.  

Toward this end, the Working Group will catalogue existing approaches
to conference control, identify the requirements for providing these
services across the general Internet, then define a small, but broad
set of conference styles that are most useful to support.  For
instance, we anticipate the need to accommodate both loose- and
tightly-controlled sessions.  Ultimately, the WG will work to specify,
implement and deploy the confctrl protocol within IETF teleconferencing
software over the MBONE.  While scalability will be a critical design
goal, the full implication of security is likely to be addressed at
later stages in the effort.

This Working Group falls under the supervision of the Remote
Conferencing Architecture steering group.  As such, it will provide an
interface to the Realtime Transport Protocol proposed in the
Audio/Video Transport Working Group.  In addition, this Working Group
will track the progress of other groups as they relate to the confctrl
effort: directory services for cataloguing users and conferences,
resource reservation and management at the network level, schemes for
multicast address allocation.

Goals and Milestones: 
 
   Mar 93 Prepare a bibliography of current readings in this area.

   Mar 93 First BOF/Working Group meeting. Review and approve the Charter,
	  making any necessary changes.  Discuss existing prototypes,
	  the issues they raise, and the unifying themes.  Identify scope 
	  and functional requirements for this service.  Outline a 
	  framework for the solution.  Assign writing assignments for 
	  first draft of document.  Begin documenting a strawman protocol.

   May 93 First draft of specification to be completed.  Provide
	  information on motivation for this work, relevance to other
	  IETF efforts, Internet teleconferencing infrastructure assumptions, 
	  and protocol details.

   Jul 93 Review first draft document and determine necessary
   	  revisions.  Follow up discussion to occur on mailing list
	  and via teleconferences.

   Oct 93 Finalize revisions for a second draft.

   Dec 93 Make document an Internet Draft.  Continue revisions based
	  on comments received.  As proof of concept and to measure 
	  thoroughness, consistency and simplicity, begin implementation.

   Mar 94 Review final draft and give to IESG for publication as an
	  RFC.

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 23 Mar 93 15:19:14 +0000

>Agenda for the Conference Control BOF (confctrl)

Such Distributed Systems will soon be torn apart by internal
contradictions if the revolution is not in time!

1. In the Prepare Project, we are trying to a management system for 
build a Virtual Private Network. This is a distributed system that
spans many management domains (called customer premises networks,
public networks and others), VPN MIS. It then hides the internals of
the private and public networks, and provides a single service access
point for signalling, management etc Our test application is
Multimedia Conferencing.

2. In MICE, we are trying to build distributed access to a centralised
Conference Management and Multiplexing Centre (CMMC), with a unified
interface to "segment managers" each of which need to be setup to
build the paths from source to destination sets of users.

However, according to 1, you dont get any paths at all until the management has
been asked to set them up, while 2 would view the control paths as present,
even if the data (e.g. video/audio) ones aren't yet, so the CMMC can
set them up....

i.e. we have a deadly embrace - the distributed net managers can only find 
out what paths to create if the distributed application tells them.
THe distributed application can only build its paths if it can find
out the path attributes required by other members of the distributed 
conferences... but it can't see them to ask them!

One solution is to permit low bandwidth control traffic i.e. the
'signalling channel' MUST be open all the time, and must carry modest
amounts of distributed applciation information between peer entities
in the conferencing system AS WELL AS management information...

However another solution that we hope to follow in the later stages of PREPARE,
but have already started on (re:COOPARE), is off loading some of the 
conferencing  system functionality onto the VPN. Initially by incorporating 
what is  currently in the CAR directory service as VPN services, 
i.e. registration of users and endpoints. 
This then could be expanded to include information on the
capabilities of the multimedia equipment and applications at each workstation
(in some common representation) to ensure connections with suitable QoS 
are established (the VPN will already know about network resources). 

The plan is for the creating user to request the conference be established
with media quality specified in freindly terms, e.g. "full speed monochrome
video" or "CD quality audio", or more likely in categories that the user
quickly become used to, e.g, high, medium, low quality. This then sets bounds
within which the VPN tries to supply the best QoS bearing in mind (processor?)
what is available as both network resources and workstation capabilities.

Another view of this paradox is that the B-ISDN community is
telco/connection-obsessed while the Internet community isn't:-)

comments...

cheers
jon

coming soon - the public src release of the Car Meta-Conferencing System!
watch this space.