Subject: Re: qb - a new floor ctrl tool fro asking questions

From: Ross Finlayson <[email-masked]>
Date: Tue, 22 Apr 1997 21:48:08 -0700 (PDT)

>Participants can indicate a desire to ask a question by
>typing in a few keywords (or the actual question if they do not have a
>microphone connected). The moderator can then either read the question and
>verbally respond, or can grant the floor to the participant allowing him to
>ask his question by talking into his microphone. Qb works in conjunction
>with vic & vat.

How, if at all, do you enforce this 'floor control'?  I.e., what's to stop
someone from chiming in with a question (via the audio channel) without
going through your floor control mechanism?

I can imagine implementing some sort of manditory floor control using
public-private key pairs and digital signatures: Questions (whether audio or
text) would be signed in some way.  Each listener has a public key to verify
the signature on a question, but only the person who's been given the floor
has the private key necessary to 'sign' his question.  (You'd need to have
some way of having the key change each time a new person is given the floor.)

But if the 'floor control' mechanism is voluntary - as I suspect this one is
- then why bother?  Multicast-based schemes that rely on all participants
behaving nicely aren't very practical (except in very constrained
environments), IMO.

        Ross.

---

From: Ben Anderson <[email-masked]>
Date: Wed, 23 Apr 1997 10:18:50 +0100

>behaving nicely aren't very practical (except in very constrained

I disagree, virtually all of our real-world group interactions rely on
people behaving nicely backed up by social, cultural and (if necessary)
legal re-inforcement. Turn-taking in meetings depends on context and social
mores NOT physically imposed gagging (usually ;-)...

IMO one of the great things about the MBONE tools as currently used is that
we have been able to use them to support a range of group communication
contexts without the need for any technically imposed 'turn-taking'. I take
this as a demonstration that social regulation (ie assuming that people
will behave nicely) can work across a range of environments.

The interesting issue is where (and why) it does not.

Ben.
-----------------------------#@theOffice#-----------------------------
Tel: 01473 644767		MLB 2/8, BT Labs, Martlesham Heath
Fax: 01473 637557		Ipswich, Suffolk, UK. IP5 7RE

---

From: Carsten Bormann <[email-masked]>
Date: 23 Apr 1997 12:24:53 +0200

> mores NOT physically imposed gagging (usually ;-)...

The problem is that it's hard to be "nice" to each other in a
bandwidth-constrained, high-delay channel.  For instance, it is rare
that you will be as aware of, say, ten other conference participants'
facial expressions in a teleconference as you easily can be in a
physical meeting.  Subtle cues to what's nice and what's not get lost.

Machine support for being "nice" (i.e., group organization) certainly
helps, if it can be made inobtrusive and easy to handle.  That
property, however, is not easy to achieve -- this may be one reason
many people who have tried floor control systems etc. dislike them.

Gruesse, Carsten

---

From: Radhika Malpani <[email-masked]>
Date: Wed, 23 Apr 1997 07:13:10 -0700 (PDT)

> behaving nicely aren't very practical (except in very constrained

Qb does send the grant-floor directive to vic & vat using the conference bus
mechanism. The idea is to have vat start with muting all participants and
then have it unmute participants that currently have the floor. However, vic/vat 
have not yet been modified to understand the messages. So currently there is 
nothing to stop someone from chiming in with a question. So right now the
floor control mechanism IS voluntary, where participants wait until they
have been granted the floor before talking. Qb is still very useful as it
lets participants know when they can ask a qs without interrupting the
speaker or other participants. Think of it as currently replicating the
raised hand analogy of a local audience, for the mbone audience. It
effectively allows participants to raise their hand in such a way that others
including the speaker can see it, and lets the speaker nod/point to a
participant granting him the floor.

-Radhika 

------------------------------------------------------------------------
Radhika Malpani				[email-masked]
Berkeley Multimedia Research Center	http://www.cs.berkeley.edu/~radhika

---

From: Jeff Smith <[email-masked]>
Date: Wed, 23 Apr 1997 09:00:00 -0700

In our experience, the trick is to support changing schemes for
floor/social control that occur even during the same session of the
same participants.  Any one control mechanism may not be appropriate
during a meeting where, for example a presentation is made,
brainstorming is done, and some decisions need to be made (possibly
using voting).

There is not a "one size fits all solution" - particularly the
technological solution - but social systems tend to be more flexible
and appropriate among a group of people who are "well acquainted" and
can detect the subtle cues (made even more subtle because of limited
bandwidth, long delay).

In any case, this is one interesting area of research (for both types
of protocols - social and network :) ...

js

|Ben Anderson <[email-masked]> writes:
|
|> At 21:48 22/04/97 -0700, Ross Finlayson wrote:
|> >
|> >- then why bother?  Multicast-based schemes that rely on all participants
|> >behaving nicely aren't very practical (except in very constrained
|> >environments), IMO.
|> >
|> 
|> I disagree, virtually all of our real-world group interactions rely on
|> people behaving nicely backed up by social, cultural and (if necessary)
|> legal re-inforcement. Turn-taking in meetings depends on context and social
|> mores NOT physically imposed gagging (usually ;-)...
|
|Carsten comments:
|
|The problem is that it's hard to be "nice" to each other in a
|bandwidth-constrained, high-delay channel.  For instance, it is rare
|that you will be as aware of, say, ten other conference participants'
|facial expressions in a teleconference as you easily can be in a
|physical meeting.  Subtle cues to what's nice and what's not get lost.
|
|Machine support for being "nice" (i.e., group organization) certainly
|helps, if it can be made inobtrusive and easy to handle.  That
|property, however, is not easy to achieve -- this may be one reason
|many people who have tried floor control systems etc. dislike them.
|
|

---

From: Larry Rowe <[email-masked]>
Date: Wed, 23 Apr 1997 09:02:13 -0700

Hi -

We implemented the questionboard tool for several reasons.

1. We hoped that it would encourage more people to ask questions.  Our 
multimedia seminar gets essentially no remote questions.  Part of it is the 
poor audio/video support in our classroom.  That's being fixed.

But still, people don't ask questions.  Here's some possible reasons.

2. They don't have microphones and (optional) cameras connected to their 
computers.  It's a little hard to ask a question when you have to worry about 
getting everything working.
SOLUTION: allow folks to type questions 

3. The social protocol for asking a question is not supported.  As said by 
Carsten, there are very subtle signals in the protocol including
+ audience member raises hand, speaker recognizes questioner
+ speaker sees quizzical look on audience member's face or someone start to 
raise their hand, but then take it down.  speaker asks explicitly whether the 
person has a question -- note: this encourages questions
+ speaker invites questions -- important because people are intimidated, so 
enocouragement is often required

4. Very long latency in communication.  This can be due to communication 
distance over low bandwidth links or it can be due to the long playout delay 
imposed by some mbone viewers (e.g., the Precept viewer delays playout by 1-2 
seconds to buffer against network congestion and synchronize audio and video 
streams).  It is well known in the telco industry that round trip 
communication must be under 300-400 msecs or you get awkward communication.

Our idea with qb was to attempt to solve some of these problems.  By allowing 
people to enter requests and/or text questions, it avoids problem of turn 
taking and absence of microphones.  The system also allows people to enter 
private and anonymous questions.  Maybe none of this will work, but we have to 
do something to improve the interactivity for remote viewers.

So, give it a try and *ask* a question today.
	Larry
-- 
Professor Lawrence A. Rowe               Internet:  [email-masked]
Computer Science Division - EECS         Phone: 510-642-5117
University of California, Berkeley       Fax: 510-642-5615
Berkeley, CA 94720-1776
URL: http://www.bmrc.berkeley.edu/~larry

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 23 Apr 1997 17:15:18 +0100

>In our experience, the trick is to support changing schemes for
                                          or charging schemes:-)

jon

---

From: Radhika Malpani <[email-masked]>
Date: Wed, 23 Apr 1997 10:06:51 -0700 (PDT)

> brainstorming is done, and some decisions need to be made (possibly
Agreed. We have tried to design the qb protocol so that it could be
extended and applied to other floor control policies, but the qb
tool itself is specifically designed for large-scale mbone seminars --
where a speaker gives a talk and audience members may ask questions.

-Radhika

---

From: [email-masked]
Date: Wed, 23 Apr 1997 10:23:27 PDT

When we have hosted such activities as connecting the MBone to PBS call-in
shows, it was common practice to require potential participants to contact
someone acting as a screener, or floor manager if you will, on a different
multicast group.  The screener would then queue people up and indicate when
each participant should join the actual show.

I'd expect this tool to do at least as good a job, with a lot less hassle, than
that lash-up.

Dan Swinehart

---

From: Radhika Malpani <[email-masked]>
Date: Wed, 23 Apr 1997 11:25:21 -0700 (PDT)

qb does NOT use unicast -- it only uses multicast fro everything. Firewalls 
were one of the reasons in the consideration.

-Radhika

> 
> Larry Rowe <[email-masked]> wrote:
> Unfortunately, the fact that qb uses unicast to communicate with the
> moderator means that I can't use it because of my firewall.
> 
> I think it might be worth revisiting the protocol to see if there's
> a good way to use multicast for everything.
> 
>   Bill
> 
>

---

From: Bill Fenner <[email-masked]>
Date: Wed, 23 Apr 1997 11:21:35 PDT

Bill

---

From: "Louis A. Mamakos" <[email-masked]>
Date: Wed, 23 Apr 1997 15:38:24 -0400

Why wouldn't a unicast stream to the conference-coordinator be the right
thing in this environment?  For large audiences, you've probably already
arranged for the propagation from the conference source to be robust and
well engineered.  In this way, there would be no opportunity for, er, 
uninvited comments from individual to go out to the rest of the conference
participants.

The screener/moderator could also mix other audio/video sources with the
new participant before having it transmitted to the multicast infrastructure.

Louis Mamakos

---

From: Radhika Malpani <[email-masked]>
Date: Wed, 23 Apr 1997 14:40:35 -0700 (PDT)

> new participant before having it transmitted to the multicast infrastructure.
Couple of reasons for using multicast to the moderator:
1) There are several sites behind firewalls configured to only pass
multicast packets
2) multicasting to the moderator makes the protocol more flexible allowing
extensions to multiple moderators and dynamically changing moderators which
might be required for other floor control policies.

Radhika

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 24 Apr 1997 09:04:44 +0100

>new participant before having it transmitted to the multicast infrastructure.

Louis 

well, we wrote a floor control application with our CCCP protocol
(uses local conf bus to actually control apps same as qb, but uses
CCCP (sigcomm 95 paper decsribes this)

this uses multicast, beacause we modeled floor contropl with a simple
finte state machine (idle, requesting, holder) - we multicast the
request and build a "sort of FIFO multicast" channel out of CCCP, so that
requests arrive at all participants (at least all listening on the
floor control channel!), ordered by who sent them first (approx), but
don't stop someone moving from sending a requerst and changing state
from idle to requersting  - the requersts are all queued at ALL
participants, and the one who currently has the floor simple responds
(to all) to say who gets it next - this minimizes latency......and is
real simple to implement......and is fair (modulo how FIFO our channel
is - we don;t make allowqances for different transit dfelays so in
principle, just as DQDB is unfair to people at the ends of a long dual
bus, our scheme is potnetially unfair to distant floor
requestors....we could run NTP and actually order reqursts in time, i
spose.....and limit the delivery of messages to the floor control
application until the worst case 1 way delivery delay (assuming no
loss - if you try and make the fifo channel reliable _underneat_ the
application, you get  into a  whole can of worms - we assume people
just _ask again_.....if they don't see an eventual response....

["orphan" state for requestors at participants who never had the floor
so can't grant it, created by messages which were not delivered to an
eventual floor holder simply pruned at receiver by the grant messages
for a _later_ request, so the whole system makes progress, but can
lead to unfairness for people on lossy links....or in some really
pathological setup with two people trading the floor too and fro while
a lot of other people behind some lossy interconnect aren't able to
get a request noticed....)

unfortunately, CCCP is fairly flakey (i messed up isidor kouvelas'
original implementation in a port, and it didn't really survive) so
the code is fairly gothic.......so lets see how Qb is.....

cheers

 jon