Subject: Re: Signal Queuing

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 8 Dec 1999 10:22:31 -0600

Thanks for engaging me on this one.

> -----Original Message-----
> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: Wednesday, December 08, 1999 8:18 AM
> To:   [email-masked]
> Subject:      Re: Signal Queuing
>
> I think the mechanism might make sense in a trunk gateway,
> but doesn't in a residential gateway.  I don't like features
> built into the protocol that have that characteristic.
        [[TomT]]
        Agreed that we don't want to impose pain on one application to feed
another.  As I've proposed it, I think I meet that criterion.  We do end up
with one or two extra ROOT properties for every MG.  As opposed to that,
someone may actually think of an use for this stuff.

> If
> a gateway is allowed to set numQueues=1 and queueLength=1,
> how does an MGC cope, and if it can, why do we need the
> mechanism?
        [[TomT]]
        Even queueLength=1 is meaningful, since it protects any signal until
it completes unless the MGC turns it off explicitly.  As an alternative, we
could require a minimum queue length of 2 (or more) if queuing is supported
at all.

> Does the <ordered list of signals> behave as if there were
> individual <push> operations, one per signal?  I hope so.
        [[TomT]]
        Yes, that's how I see it.

> How do events affect queues?
        [[TomT]]
        I would propose that events in a top-level event descriptor have no
effect, unless the event has an embedded  FLUSH signal.  The basic concept
is that queued signals have a special protected status.   If individual
queued signals have embedded events, I suppose we should let those events
have their natural effect, but only on the signal to which they are
attached.

        This may be too messy -- other people may want to comment.

> Are there completion events?
        [[TomT]]
        Seems reasonable that they could be embedded against individual
signals pushed onto the queue, unless we provide equivalent semantics
through a default parameter attached to every signal (not just queued ones).

> Why would I ever put more than one entry in any queue other
> than one queue?  Name a circumstance where I have more than
> one signal playing simultaneously, and then I want to play
> more than one signal simultaneously, but after something I
> have already queued?  Can the mechanism be one queue, and
> multiple simultaneous single signal "registers"?
        [[TomT]]
        I'd have to think about it.  All I did was match the theoretical
capability Christian and Stephen were asking for, in a simpler way than
them.  (But you have to decide in advance that you want a particular signal
to be handled according to queue semantics.)

> Suggest a syntax.  Something like Signal=<queue>{[FLUSH,]
> sig1, sig2,...}?
        [[TomT]]
        Looks possible, though I'd put it down a level
        i.e. Signal={sig1, <queue>{[FLUSH,] sig2, sig3,...}   }

> How do I handle on/off signals?
        [[TomT]]
        Don't put them into a queue.  Alternatively, allow them in, but only
if they have embedded events to stop them.  I don't like this alternative
myself -- seems too dangerous.

        Thanks again for your engagement.

> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:[email-masked]]
> > Sent: Tuesday, December 07, 1999 10:53 PM
> > To: [email-masked]
> > Subject: Signal Queuing
> >
> >
> > Jon Steer's note has suggested to me an approach to signal
> > queuing which
> > keeps the book-keeping within bounds.  The principles are as follows:
> >
> > Each MG supports N queues per termination, numbered 1..N.
> > The value of N is
> > an MG-specific property.  The signals in different queues play
> > simultaneously.
> >
> > The operations which the MGC can perform on queues are as follows:
> > push{queue number, ordered list of signals}
> > flush{queue number}.
> > The latter operation is the only way to stop playout of the
> > signals in a
> > queue -- queue playout is unaffected by the loading of a new
> > SignalsDescriptor.
> >
> > The current contents of each queue are returned by
> > AuditValue{SignalsDescriptor}.
> >
> > Signals placed into a queue MUST be either BR
> > (pre-provisioned duration) or
> > TO (explicit timeout).
> >
> >
> > Tom Taylor
> > Advisor -- IPConnect Standards
> > E-mail: [email-masked] (internally, Tom-PT Taylor)
> > Phone and FAX: +1 613 736 0961
> >

---

From: Christian Groves <[email-masked]>
Date: Thu, 9 Dec 1999 16:02:04 +0100

G'Day Tom,

I think your proposal has merits. Please see some clarification
questions below.

Cheers, Christian

Tom-PT Taylor wrote:
>      Agreed that we don't want to impose pain on one application to
>      feed another.  As I've proposed it, I think I meet that
>      criterion.  We do end up with one or two extra ROOT properties
>      for every MG.  As opposed to that, someone may actually think of
>      an use for this stuff.
>
>      If
>      Even queueLength=1 is meaningful, since it protects any signal
>      until it completes unless the MGC turns it off explicitly.  As an
>      alternative, we could require a minimum queue length of 2 (or
>      more) if queuing is supported at all.

[CHG] I would consider queueLength=1 does turn queuing off. You should
get an error if you try to queue another signal while the original one
is active.

>      Yes, that's how I see it.

[CHG] That's how I see it to. Does this mean that everytime we apply a
      signal that it must have a queueID?
                  ie    (qID,(S1),[PUSH/FLUSH])
                        (qID,(s2,s3,s4,s5),[PUSH/FLUSH])
      I'm happy that it does. I just wanted to clarify this.
>      I would propose that events in a top-level event descriptor have
>      no effect, unless the event has an embedded  FLUSH signal.  The
>      basic concept is that queued signals have a special protected
>      status.   If individual queued signals have embedded events, I
>      suppose we should let those events have their natural effect, but
>      only on the signal to which they are attached.
>

[CHG]  I think that the rules that you stated apply. Things are done
       explicitely. Can you explain however the statement about queued
       signals having embedded events?

>      signals pushed onto the queue, unless we provide equivalent
>      semantics through a default parameter attached to every signal
>      (not just queued ones).
>
>      capability Christian and Stephen were asking for, in a simpler
>      way than them.  (But you have to decide in advance that you want
>      a particular signal to be handled according to queue semantics.)

[CHG] We need to keep things flexible. Lets not start imposing rules
that don't need to be there.

>      i.e. Signal={sig1, <queue>{[FLUSH,] sig2, sig3,...}   }

[CHG] Where does the streamID come into play?
       Signal =StreamID{<queue>,sig1..,[FLUSH]}     or
       Signal ={<queue>,StreamID{sig1..,[FLUSH]}}
      Do we assume sig1 in your example above is default <queue>?

>      Don't put them into a queue.  Alternatively, allow them in, but
>      only if they have embedded events to stop them.  I don't like
>      this alternative myself -- seems too dangerous.
[CHG]  Allow them. People should be aware of the consequences. OO makes
sense if its the last one in the queue.