RE: [XCON] Comment on floor control requirements

[Xiaotao Wu <[e-mail]>]

On Wed, 12 Nov 2003, Michael Hammer wrote:

> 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.
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

>
> Mike
>
> At 11:15 PM 11/11/2003 -0500, Xiaotao Wu wrote:
> >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     : [e-mail], [e-mail]
> >Homepage  : http://www.cs.columbia.edu/~xiaotaow
> >Phone     : [phone],  Fax: [phone]
> >Phone-PC  : [phone]
> >SIP       : sip:[e-mail]
> >Office    : Room 506, Mudd building, West 120th
> >===========================================================
> >
> >On Tue, 11 Nov 2003, Marcus Brunner wrote:
> >
> > > 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)"
> > > <[e-mail]> 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
> > > > [e-mail]
> > > > tel: [phone]
> > > >
> > > >> -----Original Message-----
> > > >> From: Marcus Brunner [mailto:[e-mail]]
> > > >> Sent: 11 November 2003 16:16
> > > >> To: Drage, Keith (Keith)
> > > >> Cc: [e-mail]
> > > >> 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
> > > >> > [e-mail]
> > > >> > tel: [phone]
> > > >> >
> > > >> > _______________________________________________
> > > >> > XCON mailing list
> > > >> > [e-mail]
> > > >> > https://www1.ietf.org/mailman/listinfo/xcon
> > > >>
> > > >>
> > > >>
> > > >> --------------------------------------
> > > >> Dr. Marcus Brunner
> > > >> Network Laboratories
> > > >> NEC Europe Ltd.
> > > >>
> > > >> E-Mail: [e-mail]
> > > >> WWW:    http://www.ccrle.nec.de/
> > > >> Phone: [phone]
> > > >> Mobile: [phone]
> > > >> personal home page: http://www.brubers.org/marcus
> > > >>
> > > >>
> > >
> > >
> > >
> > > --------------------------------------
> > > Dr. Marcus Brunner
> > > Network Laboratories
> > > NEC Europe Ltd.
> > >
> > > E-Mail: [e-mail]
> > > WWW:    http://www.ccrle.nec.de/
> > > Phone: [phone]
> > > Mobile: [phone]
> > > personal home page: http://www.brubers.org/marcus
> > >
> > >
> > >
> > > _______________________________________________
> > > XCON mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/xcon
> > >
> >
> >
> >_______________________________________________
> >XCON mailing list
> >[e-mail]
> >https://www1.ietf.org/mailman/listinfo/xcon
>


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