Subject: RE: [Speechsc] Issues around grammar lifetimes

From: "Carter, Jerry" <[email-masked]>
Date: Wed, 12 Apr 2006 10:19:34 -0400

As I discussed, MRCP servers have finite resources available.  When an MRCP
server is asked to track several large grammars, it may be necessary to
purge older grammars from cache to process new requests.  Consider this
case:

DEFINE-GRAMMAR Large_1 
DEFINE-GRAMMAR Large_2
DEFINE-GRAMMAR Small_3
RECOGNIZE (against Large_1, Large_2, Small_3)
DEFINE-GRAMMAR Large_4
RECOGNIZE (against Large_4)
DEFINE-GRAMMAR Large_5
RECOGNIZE (against Large_5)
DEFINE-GRAMMAR Large_6
RECOGNIZE (against Large_1, Small_3, Large_6) << What happens?

The session starts and recognition occurs against several grammars.  The
second recognition (perhaps a modal VXML dialog) requires only a single
grammar.  Likewise, the third recognition (perhaps another modal VXML
dialog) requires only a single grammar.  For the final recognition, another
large grammar is required.  If the MRCP server is resource constrained, one
or more of the earlier grammars will be flushed from cache to make space for
the new grammar.  Let's assume that Large_1 gets flushed; the RECOGNIZE will
fail.

As I discussed, there is no language in the MRCP specification describing
grammar lifetimes nor do I see any notification mechanism that would
informing the client of which grammars are unavailable to permit a recovery.
I see this as a serious and significant deficiency.

For additional comments and a proposed solution, I refer back to the 24
March email.

> -----Original Message-----
> From: Burger, Eric [mailto:[email-masked]]
> Sent: Saturday, April 08, 2006 11:00 PM
> To: Carter, Jerry
> Cc: [email-masked]
> Subject: RE: [Speechsc] Issues around grammar lifetimes
> 
> >>> An MRCP server SHOULD retain grammars on each session created by a
> DEFINE-GRAMMAR message until at least the next RECOGNIZE.  It MAY retain
> grammars for much longer. <<<
> 
> Under what circumstance would an MRCP server *not* retain the grammar?  If
> you cannot think of one, and this is important, than an MRCP server MUST
> retain grammars until the next RECOGNIZE.  Conversely, if there are too
> many circumstances when the MRCP server would not retain the grammar,
> there is no point saying it should, because implementers will do whatever
> they want, anyway.
> 
> In general, if we have a statement that X SHOULD do Y, then in the same
> paragraph one needs to enumerate when X would NOT do Y.
> 
> ________________________________________
> From: Carter, Jerry [mailto:[email-masked]]
> Sent: Friday, March 24, 2006 11:25 AM
> To: [email-masked]
> Subject: [Speechsc] Issues around grammar lifetimes
> 
> Typically, an MRCP client will issue multiple DEFINE-GRAMMAR messages
> eventually followed by a RECOGNIZE.  The MRCP client might reasonably
> expect that the defined grammars would be available when recognition is
> requested, but this does not appear to be guaranteed.  Furthermore, I do
> not see any notification mechanism for informing the client of which
> grammars are unavailable.
> 
> 
> There does not appear to be any language in section 9 that describes
> grammar lifetimes.  There is language in the session URI description
> (section 13.7) that might relate
> 
>       The purpose
>       of this scheme is to permit access to the specific resource for
>       the lifetime of the session with the entity storing the resource.
> 
> but this is not a normative statement requiring availability for a session
> lifetime.  In practice a MRCP server has a finite cache and may support
> multiple parallel sessions.  It is unreasonable to require that the MRCP
> server provision a sufficiently large cache to store all grammars across
> all sessions, particularly if sessions are long and employ large dynamic
> grammars.  Such a requirement would render small footprint MRCP servers
> impossible.
> 
> If a grammar is flushed from the MRCP server's cache before RECOGNIZE, the
> notification mechanism is unclear.  Presumably a completion cause of
> 'grammar-load-failure' would be returned.  The server might want to return
> a list of URIs in the message but this would violate 9.4.12
> 
>    Clients SHOULD NOT interpret the completion reason text.  Instead it
>    is RECOMMENDED that the reason be recorded in client logs and
>    otherwise made available for debugging and instrumentation purposes.
> 
> and such an approach would need to be standardized.  Additionally, a
> developer would like some assurance _before_ RECOGNIZE is invoked that all
> the loaded grammars are available.
> 
> 
> Because MRCP servers have finite memory and caches, it is not reasonable
> to require that grammars be available on a session indefinitely after a
> DEFINE-GRAMMAR.  We might instead require that grammars have guaranteed
> availability on a session only until the next call to RECOGNIZE; this also
> breaks for the same reason.
> 
> 
> Here is a solution that I believe works.
> 
> (1) An MRCP server SHOULD retain grammars on each session created by a
> DEFINE-GRAMMAR message until at least the next RECOGNIZE.  It MAY retain
> grammars for much longer.
> 
> (2) DEFINE-GRAMMAR should support redefining grammars by passing the IDs
> without supplying the grammar definition.  The text/grammar-ref-list media
> type might be appropriate for this purpose.
> 
> (3) A RECOGNIZE or a DEFINE-GRAMMAR returning a completion cause of either
> 'grammar-load-failure' or 'grammar-completion-failure' should include a
> CRLF separated list detailing the IDs which grammars did not load or
> compile.
> 
> (4) The text in 9.4.11 should support DEFINE-GRAMMAR returning 'grammar-
> load-failure' and 'grammar-completion-failure'.
> 
> -------------------------
> 
> Under this proposal, the client might do the following:
> 
> DEFINE-GRAMMAR documentLevel1 (new definition)
> DEFINE-GRAMMAR documentLevel2 (new definition)
> DEFINE-GRAMMAR formLevel1 (new definition)
> DEFINE-GRAMMAR fieldLevel1 (new definition)
> RECOGNIZE
> 
> DEFINE-GRAMMAR documentLevel1 documentLevel2 formLevel1 (IDs only to
> reassert continued need)
> DEFINE-GRAMMAR fieldLevel2 (new definition)
> RECOGNIZE
> 
> -------------------------
> 
> Likewise, in the typical error case:
> 
> DEFINE-GRAMMAR documentLevel1 (new definition)
> DEFINE-GRAMMAR documentLevel2 (new definition)
> DEFINE-GRAMMAR formLevel1 (new definition)
> DEFINE-GRAMMAR fieldLevel1 (new definition)
> RECOGNIZE
> 
> <time passes during which documentLevel2 gets flushed from the server's
> cache>
> 
> DEFINE-GRAMMAR documentLevel1 documentLevel2 formLevel1 (only to reassert
> continued need; an error is returned indicating that documentLevel2 could
> not load)
> DEFINE-GRAMMAR documentLevel2 (new definition)
> DEFINE-GRAMMAR fieldLevel2 (new definition)
> RECOGNIZE
> 
> -------------------------
> 
> Furthermore, if the client believes that the server has sufficient storage
> capabilities, the existing protocol may be followed.
> 
> DEFINE-GRAMMAR documentLevel1 (new definition)
> DEFINE-GRAMMAR documentLevel2 (new definition)
> DEFINE-GRAMMAR formLevel1 (new definition)
> DEFINE-GRAMMAR fieldLevel1 (new definition)
> RECOGNIZE
> 
> <time passes, but grammars are not flushed>
> 
> DEFINE-GRAMMAR documentLevel2 (new definition)
> DEFINE-GRAMMAR fieldLevel2 (new definition)
> RECOGNIZE
> 
> Here the client is taking a chance that RECOGNIZE will fail because a
> grammar is not available, but finds that an acceptable risk.  Were
> RECOGNIZE to return with 'grammar-load-failure', the client would still be
> able to recover - though the user might experience some undesired latency.
> 

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

---

From: David R Oran <[email-masked]>
Date: Wed, 12 Apr 2006 11:06:51 -0400

This strikes me as something that should not be exposed to the client  
unless there is really strong reason to believe that the client can  
do a better job of managing server resources than the server can itself.

Dave (chair hat off)