Subject: BOF template

From: Chip Elliott <[email-masked]>
Date: Mon, 15 Mar 93 11:06:18 EST

Conference Control BOF Template
		    -------------------------------

1. Name of project, program and/or protocol.

	"VideoTeam" is the project/program name.

	"Sticky" is the protocol name, for lack of anything better.

2. Contact person, affiliation and e-mail address.

	Chip Elliott		[email-masked]

3. Target operating environment and key design considerations:

   - WAN vs LAN 
   - digital vs analog media
   - the kinds of collaborative media used in your system 
     (e.g., real-time audio, video, animations, landsat images) 
   - packet technology vs ISDN
   - room-to-room vs desktop conferencing
   - ???

	Designed specifically for Defence Simulation Internet requirements.
	Real business conferences, hence emphasis on reliability and
	ease of use. Must try to provide good services atop a real-
	world WAN.

	Used either point-to-point or for group meetings with <=5 sites.
	Realtime audion/video.

	Room-to-room with PictureTel codecs, packetized, and distributed
	via a WAN with bandwidth reservation and multicast. Audio sent
	inband or (soon) via separate packet stream for local mixing.

	Occasionally used with other multimedia collaboration tools,
	eg, shared maps, documents, and whiteboard.

	Other design goals include possible migration to other codecs,
	desktop conferencing, and perhaps non-Unix. Scalability and
	"lecture-mode" ideas were given some consideration, though not
	for any specific present reason.

4.a Type of conference styles supported by your system/protocol.

	Point-to-point.

	Small group, unmoderated.

	Small group, moderated.

	Exclusive or non-exclusive conferences. In non-exclusive ones,
	sites may come and go. There are no "special" sites at any time,
	such as a "conference initiator".

	Designed to scale up to large broadcasts, etc; but never tried.

4.b Profile of user community: 

   - expertise level 

	Users are completely non-technical. They have a support staff
	to handle technical matters.

   - formality of meetings

	Varies from extremely formal (ie, rehearsed 4-5 times with
	standins before actual conference) to completely informal.

   - demand for quality of service

	Service must work reliably all the time. It is considered
	on a par with telephone service.

5. Architecture assumptions: 

   - distributed vs centralized model

	Completely distributed. No central points even at startup.

   - system component(s) responsible for conference control

	VideoTeam itself contains all conference control mechanisms.

   - degree of homogeneity in end-system capabilities 

	Currently very homogenous, but designed to handle a very
	wide range of capabilities via a resource-negotiation mechanism.

   - multicast integration

	Handles both multicast and point-to-point.

   - directory services

	None. Configuration files are distributed by hand from time
	to time.

   - support for quality of service

	Protocol supports negotiation, but currently it's an
	all-or-nothing affair.

   - ???

	Handling network outages, site equipment failures, etc.,
	was considered highly important.

	Efficient use of WAN bandwidth was also considered very
	important.

6.a How do you define conference control?  

	The mechanism(s) by which people or groups of people can
	arrange to meet, moderate their meetings, and bring a
	meeting to a close. This should include provisions for
	people or groups joining a meeting late and/or leaving early.

	A strongly related issue is "resource management" which
	includes negotiation of compatible modes, bandwidths, etc,
	among all equipment which is used to provide services and
	all people which will have to put up with these services.

6.b Conference control functionality supported.

	"Connecting" 2 or more site into a conference.

	"Disconnecting" a site from an ongoing conference.

	"Merging" of previously separate conferences.

	Access control for exclusive conferences.

	Floor control for moderated conferences.

	Negotiation of media resources when sites wish to
	view one another.

6.c Other control functions you would like to support.

	Better negotiation of non-homogenous resources; which seems
	like a very hard problem in general.

7. Conference control protocol details: 

  - explicit vs implicit setup

	Sites may connect to each other at any time. Connection to
	a site typically brings about a connection to all sites that
	it is connected to, though this is a function of the
	conferenciong system rather than the protocol.

	No distinction is made between "setup" time and an "ongoing"
	conference. Connections may happen at any time and are always
	treated the same.

  - interconnectivity of participants

	The protocol/system attempts to bring full connectivity
	(on the control level) but is designed to work reliably in
	cases where that is not possible.

	As for media streams, these are created on demand, and so
	may not have full connectivity. In addition, they are destroyed
	when no longer required.

  - state sharing

	The Sticky protocol attempts to propagate state, but assumes
	that sites generally disagree about state. There is no
	distinction between an unsynchronized and synchronized state
	for a conference -- sites are always assumed to be somewhat
	out of synchronization.

  - robustness

	A key design goal. Hopefully the system is very robust.
	The Sticky protocol is designed so that sites can be fully
	independent and so that failure of sites, equipment, or
	network links do not take down the entire conference.
	In fact, it's designed to self-heal after equipment is
	brought back into operation (even after network partition).

  - scaling properties

	The Sticky protocol has been designed so that it could scale
	up (I believe) but this is not an important design goal and
	has not been tested.

  - ???

	All connections are bilateral, rather than conference-wide.
	Control packets are UDP; TCP/IP and RCP are simply not robust
	enough for real use. Media streams are via ST-II, but this
	is not strongly tied into the protocol or implementation;
	ST-II provides multicast trees for data streams.

	All resource negotiation/request takes place ON DEMAND rather
	than when a conference starts up. This "late binding" offers
	significantly different possibilities and difficulties than
	an "early binding" approach that negotiates resources at
	start-up time.

8. Hardware/software platforms.  

	At present, Sparcs with PictureTel codecs, running on top
	of the Defence Simulation Internet.

	Designed to be easy to migrate to other workstations and
	codecs, including desktop.

	Could migrate to other networks fairly easily as well,
	though bandwidth reservation and multicast are desirable.

9.a What specifically has or has not been implemented?

	Everything mentioned has been implemented, with the exception
	that resource negotiation is currently all-or-nothing rather
	than any true "negotiation".

9.b What was unexpectedly easy or difficult to implement?

	Floor control was very easy.

	A robust protocol that propagated state from site to site
	was unexpectedly hard. The result is trickier than I like.

	Eccentricities of the PictureTel codec and underlying network
	had unexpectedly large effects on the design.

9.c What might you change as a result?

	No thoughts of changing things right now.

10. If available, a couple of suggested readings about your work
    on confctrl.

	"High-Bandwidth Multimedia Conferencing Though a Long-Haul
	   Packet Network".

	"A 'Sticky' Conference Control Protocol".

	[both available in paper form; I have not yet succeeded in
	getting portable Postscript of them, alas.]

MY OWN ADDITION:

11. What else?

	VideoTeam is not a "secure" or "well-protected" system, in
	that sites masquerading as other sites could easily enter a
	conference. This is not a problem in practice but I would
	like to think more about access control and security for
	both the conference control and resource requests.

	Some issues are inherently hard to resolve in fully
	decentralized systems. For example, in a meeting of 6 peers,
	who can decide if a new site should be allowed to join the
	meeting? In physical space, this would perhaps be resolved
	by a vote and then by opening the door. I believe that
	VideoTeam allows a similar reaction by allowing participants
	to talk among themselves before accepting a new member; but
	it's possible for one site to accept the new site no matter
	what the other sites say... Is this a problem? I don't know.

	Late addition of participants can require thorough
	renegotiation of media characteristics, which is a real can
	of worms. This needs a lot of careful thought.

	Similarly, the conference participants themselves should often
	be drawn into media negotiation since they are the only ones
	who can decide whether a conference should proceed in the face
	of low-quality service, or whether it should simply be cancelled.
	Other decisions can get much more difficult -- eg, should we
	accept a non-standard codec mode now instead of say H.261 because
	we don't have the bandwidth for H.261 or whatever. Such decisions
	may preclude late entry of other participants....

----- End Included Message -----