Errors / ambiguities / problems found in specs at lastweek'sinterop

Gene Schroeder erschroeder at LUCENT.COM
Tue Mar 14 10:20:59 EST 2000


Chris,

I agree that the scenario you mention (of the endpoint asking for a larger
TTL than the gatekeeper wants) is the expected and most common one by far.
However, there might be endpoints who believe they are doing the network a
favor by providing frequent keep-alives (or who believe their status to be
more important than the gatekeeper does).  So in a case where the client
says "my registration TTL is 5 seconds, and of course I'll be notifying you
every 5 seconds that I'm still alive because I'm sure you will want to
know," it is reasonable for the gatekeeper to respond with "no, please, your
registration is good for 10 minutes, no need to burden yourself sending
those keep-alives so frequently, really, I insist" (sort of like telling
your kids to stop asking "are we there yet?" every 30 seconds while on a 2
hour trip).  Of course, the endpoint might not get the hint and send
keep-alives every 5 seconds anyhow.  If the endpoint does get the hint, but
is insulted by the insinuation, it could unregister and find someone else to
play with (just as if the gatekeeper assigned the endpoint aliases it didn't
like).  This would seem to lead to better interoperability than to have the
gatekeeper reject the RRQ, particularly since there is no explicit RRJ
reason code to tell the endpoint what the problem is.  Of course, the
standard doesn't support this TTL negotiation scenario, but it still seems
reasonable to me.

As I said, I believe that this really isn't much of a problem in practice,
but the same issue has come up in other places.  Like many other H.323
procedures, it's really just a simple case of the gatekeeper trying to use
its broader knowledge of the network/service to manage it as effectively as
possible, and for the endpoints to be good citizens and assume the
gatekeeper knows best.

Gene

> -----Original Message-----
> From: Mailing list for parties associated with ITU-T Study Group 16
> [mailto:ITU-SG16 at mailbag.cps.intel.com]On Behalf Of Chris Wayman Purvis
> Sent: Monday, March 13, 2000 12:38 PM
> To: ITU-SG16 at mailbag.cps.intel.com
> Subject: Re: Errors / ambiguities / problems found in specs at
> lastweek'sinterop
>
>
> Gene,
>
> It Simply Doesn't Work Like That.
>
> The endpoint WOULD be honouring the request if it sent RRQs "too
> frequently",
> by sending keepalive RRQs at least as often as requested - which
> is what the
> time the gatekeeper gives in RCF asks of it.
> In principle endpoints should give a time they think is
> incredibly long in RRQ
> (essentially they're saying "my timers will get confused if you
> ask them to run
> longer than this!"), and the gatekeeper cuts them down to size,
> saying "if you
> want to live in MY zone you'll behave yourself and renew your
> registration at
> least THIS often.".  There is NO way in the standard that a
> gatekeeper can ask
> an endpoint not to send it RRQs at more than a certain frequency
> - and for good
> reasons.  And it would look a little odd if you were allowed to
> send "normal"
> RRQs arbitrarily frequently, but keepAlives mustn't be more than a fixed
> frequency.
>
> If an endpoint's threatening to send keep-alives every few seconds, as you
> describe, and this is likely to cause you problems, my advice would be to
> reject the RRQ...
>
> Chris
>
> Gene Schroeder wrote:
> >
> > One common reason the gatekeeper might want to increase the
> registration TTL
> > is to control the rate of incoming keep-alive RRQs.  If a gatekeeper has
> > many endpoints registered, and these endpoints select a very
> low TTL (say a
> > few seconds), then the gatekeeper will be forced into
> processing a high rate
> > of keep-alive RRQs.  If the gatekeeper does not require nor
> need such timely
> > information on endpoint status, then IMHO it should be able to specify a
> > higher TTL in the RCF.  And it seems the endpoint should honor
> this request,
> > just as if it would honor a lower TTL.
> >
> > Regards
> > Gene Schroeder
> > elemedia
> >
> > > -----Original Message-----
> > > From: Mailing list for parties associated with ITU-T Study Group 16
> > > [mailto:ITU-SG16 at mailbag.cps.intel.com]On Behalf Of Chris
> Wayman Purvis
> > > Sent: Monday, March 13, 2000 9:02 AM
> > > To: ITU-SG16 at mailbag.cps.intel.com
> > > Subject: Re: Errors / ambiguities / problems found in specs at last
> > > week'sinterop
> > >
> > >
> > > Comments inline:
> > >
> > > "Johan Gerhardsson (ETX)" wrote:
> > > >
> > > > Hi folks,
> > > >
> > > > To clarify things:
> > > >
> > > > It seems that my writing was a bit sloppy when I wrote the
> > > problems about TTL and SEQUENCE OF... on the interop. I intended
> > > to describe two different problems:
> > > >
> > > > 1) GK cannot increase TTL in RCF.
> > >
> > > This is true.
> > >
> > > > 2) Mandatory parameters of type SEQUENCE OF ... can have empty list.
> > >
> > > This is also true.
> > >
> > > > 1)
> > > > h323v2, 7.2.2:
> > > > "The Gatekeeper may respond with an RCF containing the same
> > > timeToLive or a shorter timeToLive.".
> > > > As I see it, according to this, a GK is not allowed to increase
> > > the timeToLive value proposed by the endpoint in RRQ, regardless
> > > if the endpoint makes a full registration or a keep-alive
> registration.
> > > >
> > > > I think it should be possible for the gk to do it.
> > >
> > > I disagree.  As the endpoint is permitted to renew its
> > > registration any time up
> > > to the assigned time to live, allowing the GK to increase time to
> > > live would
> > > have no effect whatsoever (the endpoint would send keepalives
> at whatever
> > > frequency it always wanted to).  There would be no effect, so
> > > there's no reason
> > > to change.
> > >
> > > As for your second point about SEQUENCE OF being permitted to
> > > have an empty
> > > list, this has always been the case.  Is there a specific problem
> > > with this?
> > > It looks more like a (true) observation than a problem to me!  I
> > > doubt you'll
> > > get ASN.1 changed in existing stuff to make things SEQUENCE
> > > [1..something] OF
> > > rather than SEQUENCE OF (even if such a structure is
> permitted - any ASN.1
> > > experts wish to comment?).
> > >
> > > Chris
> > > --
> > > Dr Chris Purvis -- Development Manager
> > > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
> > > Winkfield Row, Berkshire.  RG42 6LY  ENGLAND
> > > Phone: +44 1344 899 007
> > > Fax:   +44 1344 899 001
> > >
>
> --
> Dr Chris Purvis -- Development Manager
> ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
> Winkfield Row, Berkshire.  RG42 6LY  ENGLAND
> Phone: +44 1344 899 007
> Fax:   +44 1344 899 001
>



More information about the sg16-avd mailing list