Subject: RE: [XCON] Comment on floor control requirements

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 11 Nov 2003 23:38:35 -0000

So firstly you do admit that the queue exists (when the number of people requesting the floor exceeds the number allowed to hold the floor. So I believe we can define the queue so that we can say meaningful things about it.

I also believe we can at least document the impact of existing requirements on the queue, e.g. if someone requests the floor, they are added to the queue until the floor chair grants the request - that after all is just documenting what already implicitly exists in the document.

The question I guess we may well differ is as to what is implementation specific, and what is actually defined in future protocol specifications as a result of requirements made in the requirements draft. I guess partly that depends on where the queue is held in relation to the floor chair. If it is in the local entity to the floor chair, then any requirements on the manipulation of the queue by the floor chair could be implementation specific. Any action by participants to see or modify the queue would have to be defined.

However, I am not convinced that we are yet at the stage where we can agree that the queue is in the local entity to the floor chair, and maybe we should have some discussion about that. My input to that would be that in the wireless world, we are interested in minimising the bits on the air interface, and if centralising the queue reduces the protocol load, then we would certainly want to consider it. There is already a requirement in the requirements draft to take account of this impact.

Certainly if they are in separate entities, we need requirements that cover the eventual protocol that must exist between the floor chair and queue, and it would be useful to also identify what of those exist.

regards

Keith

Keith Drage
Lucent Technologies
[email-masked]
tel: +44 1793 776249

> -----Original Message-----
> From: Marcus Brunner [mailto:[email-masked]]
> Sent: 11 November 2003 16:16
> To: Drage, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [XCON] Comment on floor control requirements
> 
> 
> keith,
> 
> 
> > It would appear to me that this queuing needs to be more extensively
> > discussed in the above requirements document.
> >
> 
> I think there should not be any restrictions on what queuing 
> is needed. The 
> mechanisms to be standardized should be free of any of these 
> assumtions.
> 
> > Firstly REQ-11 implies that the queue is first in, first out (and I
> > stress that this is an implication), whereas in real life 
> certain users
> > may preempt others in the queue.
> >
> > Secondly it would appear to be appropriate to have 
> requirements for the
> > floor control chair to have requirements for manipulating 
> the queue, e.g.
> > to designate the order of obtaining the floor, to clear the 
> queue and so
> > on.
> >
> 
> I assume this to be implementation specific.
> 
> > Additionally, perhaps other participants may also require 
> visibility of
> > the queue.
> >
> 
> that is good point, In draft-brunner I called it state awareness (so 
> participants should be able to get information about the 
> current state of 
> the floor control mechnisms including also the queue state.
> 
> > My proposal would therefore to update the draft to 
> explicitly define this
> > queue concept, and then to revise the requirements to reflect the
> > existence of the queue, and add requirements for the 
> manipulation of the
> > queue.
> >
> 
> I oppose, this is really implementation/application specific 
> and should not 
> influence the design of the mechnism.
> 
> Marcus
> 
> > regards
> >
> > Keith
> >
> > Keith Drage
> > Lucent Technologies
> > [email-masked]
> > tel: +44 1793 776249
> >
> > _______________________________________________
> > XCON mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/xcon
> 
> 
> 
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
> 
> E-Mail: [email-masked]
> WWW:    http://www.ccrle.nec.de/
> Phone: +49 (0) 6221 905 11 29
> Mobile: +49 (0) 163 275 17 43
> personal home page: http://www.brubers.org/marcus
> 
> 

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: Marcus Brunner <[email-masked]>
Date: Tue, 11 Nov 2003 17:54:54 -0600

keith,

the queue might exist for some floor control policies (e.g. for what i 
called the ietf model). What are the things you want to say about the 
queue? Except to distribute for example the size and on what position a 
certain participant is sitting.

Marcus

--On Tuesday, November 11, 2003 11:38 PM +0000 "Drage, Keith (Keith)" 
<[email-masked]> wrote:

> So firstly you do admit that the queue exists (when the number of people
> requesting the floor exceeds the number allowed to hold the floor. So I
> believe we can define the queue so that we can say meaningful things
> about it.
>
> I also believe we can at least document the impact of existing
> requirements on the queue, e.g. if someone requests the floor, they are
> added to the queue until the floor chair grants the request - that after
> all is just documenting what already implicitly exists in the document.
>
> The question I guess we may well differ is as to what is implementation
> specific, and what is actually defined in future protocol specifications
> as a result of requirements made in the requirements draft. I guess
> partly that depends on where the queue is held in relation to the floor
> chair. If it is in the local entity to the floor chair, then any
> requirements on the manipulation of the queue by the floor chair could be
> implementation specific. Any action by participants to see or modify the
> queue would have to be defined.
>
> However, I am not convinced that we are yet at the stage where we can
> agree that the queue is in the local entity to the floor chair, and maybe
> we should have some discussion about that. My input to that would be that
> in the wireless world, we are interested in minimising the bits on the
> air interface, and if centralising the queue reduces the protocol load,
> then we would certainly want to consider it. There is already a
> requirement in the requirements draft to take account of this impact.
>
> Certainly if they are in separate entities, we need requirements that
> cover the eventual protocol that must exist between the floor chair and
> queue, and it would be useful to also identify what of those exist.
>
> regards
>
> Keith
>
> Keith Drage
> Lucent Technologies
> [email-masked]
> tel: +44 1793 776249
>

---

From: Xiaotao Wu <[email-masked]>
Date: Tue, 11 Nov 2003 23:15:05 -0500 (EST)

I think we should not explicitly mention 'queue' in the requirement
document.

'queue' is just one way of implementing the collection for floor
requests. How to define the queue and how to operate the queue is
implementation issues. It should not be explicitly mentioned in the
protocol.

In our outdated draft draft-wu-sipping-floor-control-04.txt, we
defined several queue operations for floor requests. Now I felt that to
have the queue operations defined in a floor control protocol makes the
protocol too complicated.

I think a better way to represent the order of the requests is to use
priority value for the requests. The priority value is just optional.
In fact, for many common usages, we don't need to use the priority value
to sort the requests.

(1) for FIFO, time-stamp can be used to sort
(2) for random, (like in a big conference, it does not make sense to pick
a questioner based on who raise the hand first), no order at all
(3) for chair-controlled, unless the other participants also want to see
the order, the chair can keep the collection of requests locally on
chair's UA, and there is no need to have queue operations between the
chair and the conference server.

If we do want to have the sorted collection on conference server and
allows the chair to freely change the order, the chair can change the
priority value of a request and the order can be changed. The participants
can be notified of the priority value change and re-order their list.

I think queue should not be explicitly mentioned. Otherwise, we need
also mention the operations of the queue and make the protocol
complicated.

Thanks!

-Xiaotao

===========================================================
Name      : Xiaotao Wu
Email     : [email-masked], [email-masked]
Homepage  : http://www.cs.columbia.edu/~xiaotaow
Phone     : (212)939-7054,  Fax: (801)751-0217
Phone-PC  : (212)939-7133
SIP       : sip:[email-masked]
Office    : Room 506, Mudd building, West 120th
===========================================================

---

From: Michael Hammer <[email-masked]>
Date: Wed, 12 Nov 2003 11:16:29 -0500

Could you take an equivalent view that the time of a request is simply one 
of several attributes used to make a selection of one requesting party to 
the conference over another?  The time of arrival of a request for the 
floor could be recorded along with the other attributes of the requestor, 
and then it is a policy matter for the chair in deciding who gets the floor 
next.

Mike

---

From: Xiaotao Wu <[email-masked]>
Date: Wed, 12 Nov 2003 11:40:58 -0500 (EST)

> and then it is a policy matter for the chair in deciding who gets the floor
Hi, Mike,

Right, time is just one of the attributes, though it may be the most
important attributes. As I stated in my last email,
the order is not only based on 'time'. The chair can change the order,
for example, change the priority of a floor request.

The main point is, queue is just about how to implement the order. If we
define queue in the protocol, where will the queue reside? If the queue
resides in the conference server, should we define queue operations from
the moderator to the conference server? If we want to define the queue
operations, should we define a full-fledge queue operations for floor
control? To explicity define queue in the protocol will make the
protocol too complicated. Especially, it should not be in the requirement
document.

Thanks,

-xiaotao

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 15 Nov 2003 16:34:39 -0800

> certain participant is sitting.

Yes, the requirements you mention above look about right...

I think we needs some requirements around something sort of like a priority
queue. The requirements don't need to imply anything about what order things
come out of the queue but knowing things like current size and approximate
relative position are pretty useful.

Cullen