New subject: Errors / ambiguities / problems found in specs at last, Re: Errors / ambiguities / problems found in specs at last

14 Mar 2000

      Dear Mr. Gene,
There is an assumption in your theory that the
endpoint may be doing a favor to the network by
providing frequent keep alives. But, What I feel is,
the TTL specified by the endpoint is the value it
seems, it is going to be alive. (The definition of
being alive here may mean the agreement duration with
the service provider or it may be the time for which
you are present in the cyber cafe...). This way, the
endpoint is telling that it intends to use the
services of the Gatekeeper for this much duration.
   Now, the Gatekeeper, in opposition to this, may say
that I need to know every nth minute that you are
still there. The reason may be, every nth minute, the
gatekeeper will like to change the security
information. By forcing the endpoint to reregister
every nth second, it can change the security
information.
   And, as you yourself have said that the Gatekeeper
has better knowledge of the condition of the network.
So, given the maximum time the EP wants to work with
the gatekeeper, the GK may select the optimum value of
the TTL, which will always be less than or equal to
the TTL asked by the EP.
Please point out any mistake in this description.Your
comments are most welcome.
Regards,
Jane
------------------------------------------------------
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@mailbag.cps.intel.com]On Behalf Of
Chris Wayman Purvis
...
Sent: Monday, March 13, 2000 12:38 PM
To: ITU-SG16@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@mailbag.cps.intel.com]On Behalf
Of Chris
...
Wayman Purvis
...
...
Sent: Monday, March 13, 2000 9:02 AM
To: ITU-SG16@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:
...

GK cannot increase TTL in RCF.

This is true.
...

Mandatory parameters of type SEQUENCE OF

... can have empty list.
...
...
...
This is also true.
...

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
%3.crumb=v8.e34f9bxp, Dear Mr. Gene,
There is an assumption in your theory that the
endpoint may be doing a favor to the network by
providing frequent keep alives. But, What I feel is,
the TTL specified by the endpoint is the value it
seems, it is going to be alive. (The definition of
being alive here may mean the agreement duration with
the service provider or it may be the
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Re: Errors / ambiguities / problems found in specs at last, Re: Errors / ambiguities / problems found in specs at last

Jane Hua

Chris

Paul Long

tags (0)

participants (2)