RE: [XCON] Comment on floor control requirements

[Michael Hammer <[e-mail]>]

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

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