[robustness]Comments on TD-42/Osaka

Terry L Anderson tla at LUCENT.COM
Mon Jun 19 10:27:07 EDT 2000


See comments below.

Rich Bowen wrote:

> Robustness folks,
>
> A couple of comments on TD-42/Osaka -
>
> 1) While adding the ASN.1 from TD-42 to the draft H.225.0 v4, I noticed
> the following paragraph about using StatusInquiry as a keepalive
> mechanism:
>
> "The element closer to the called party shall send StatusInquiry
> periodically (this is the direction of least traffic during established
> calls).  The period should be configurable.  Two seconds is the
> recommended default, in order to allow detection of failure before other
> messages timeout.  The selected value must be added to StatusInquiry so
> that the recipient can also monitor failure without an additional
> StatusInquiry/Status exchange in the opposite direction.  The recipient
> system needs only to maintain a timer using the indicated value as a
> timeout."
>
> This clause indicates that the period at which StatusInquiry is sent is
> also the amount of time that the receiving system should use as a
> timeToLive timer.  This arrangement would result in a race condition
> since the next StatusInquiry would be expected at the exact moment that
> the timeToLive timer was due to expire.
>
> IMHO, the StatusInquiry period and the timeToLive should be separately
> configurable, both having default values defined in Annex R, with the
> obvious restriction that timeToLive shall be greater than the
> StatusInquiry period.

What we had in mind is essentially a duplication of the RAS lightweight
registration method.  There timeToLive is indicated by either GW in RRQ or
GK in RCF (RCF is the definitive) and is the only parameter.  It is up to
the GW to register enough earlier or the GK to allow registration to live
enough longer to avoid the race.  I would guess in practice that most
systems do both.  I see no reason the same cannot work here.  I would assume
that the recipient would add some suitable padding to the time before
concluding failure.  I see no reason to carry yet one more field in the
message.

> 2) Has consideration been given to adding the ability for the endpoint
> to indicate to the GK via the ARQ that a particular call requires
> robustness, or to allowing the GK to indicate to the EP that the EP must
> use the robustness procedure for a particular call?  Several other
> features added in v4 use this model and it seems to be a useful
> framework.

I think that the group has assumed that robustness is a property of network
elements - either it has it for all calls or none.  But we could certainly
consider it on a per call basis if this seems useful.  I suppose since there
is some processing cost associated with the mechanism, one might choose to
NOT use it for some calls even when it is available.

Do others think a per call choice is useful?

> - Rich
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com

--
------------------------------------------------------------
Terry L Anderson              mailto:tla at lucent.com
Tel:908.582.7013   Fax:908.582.6729
Pager:800.759.8352 pin 1704572   1704572 at skytel.com
Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tla.vcf
Type: text/x-vcard
Size: 548 bytes
Desc: Card for Terry L Anderson
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000619/f508dc90/attachment-0006.vcf>


More information about the sg16-avd mailing list