[Robustness] mechansims for H.450

Callaghan, Robert Robert.Callaghan at ICN.SIEMENS.COM
Mon Apr 10 16:00:12 EDT 2000


The next robustness conference call will be held on April 12 9AM EST USA.
The phone number is:

(613)688-2795
The passcode is: 9501#

You must enter the # sign after the passcode.

Agenda:

We will be discussing the IETF SCTP and DDP protocols and their
applicability to H.323 robustness.

DDP (Distributed Data protocol)
http://www.ietf.org/internet-drafts/draft-xie-stewart-sigtran-ddp-00.txt

SCTP (Simple Control Transmission Protocol)
(http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-07.txt)


Please join us.

Here are the minutes from the last robustness teleconference:


Minutes of H.323 Robustness Teleconference - April 6, 2000
Prepared by Maureen Stillman, Nokia

Next Teleconference:  Scheduled for April 12, 2000 9AM EST USA

Action items from 4/6/2000 teleconference:

        1.      Post meeting minutes to mailing list
        2.      Jorg Ott will provide failure scenarios for gatekeepers for
the Robustness Framework document.
        3.      Review Terry Anderson's H.225 and H.245 state machine
document.  We need to begin to determine what state information should be
kept and how it should be restored under different failure scenarios.
        4.      Review IETF's SCTP and DDP protocols.  Randy Smith and
Qiaobing Xie will join us to answer questions about these protocols.
        5.      Ask Bob Callahan about the robustness built into the H.450
protocol.

Attending the 4/6/2000 teleconference:

Maureen Stillman maureen.stillman at nokia.com
Sasha Ruditsky sasha at tlv.radvision.com
Paul Jones paul.jones at ties.itu.int
Randy Stewart rstewar1 at email.mot.com
Qiaobing Xie xieqb at cig.mot.com
Terry Anderson tla at lucent.com
Timothy Sipsey Timothy.Sipsey at Aspect.com

Summary of Teleconference:

Elements of call state:

We discussed the "Elements of call state" document produced by Terry
Anderson of Lucent.   What we need to do next with this information is to
determine the following:
        1)      What state information needs to be kept under what
circumstances?
        2)      What information needs to be restored under what conditions?
        3)      Where does a component get this state information?
        4)      What state information needs to be exchanged?

There needs to be some way of notating this information on the "Elements of
Call State" table that is included in the document.  If we decide to support
different levels of robustness then under different conditions some state
information will be considered vital, and some will not.  An example of this
is billing.   If billing is critical to the system, then all information
critical to billing needs to be restored, otherwise some of it can be
omitted.  We may want to specify some range of necessity of restoration of
state information.

There are two parts to the state information:

        1)      State information that is relevant to call setup
        2)      State information that is exchanged after call setup is
complete and the call is in a stable state.  State information is exchanged
in the form of messages.

We need to define what we mean by "the call is in a stable state". Some
state information might not be needed once the call setup is complete.
Additional media channels can be opened once the call is in progress.  We
have agreed to only try to restore calls that are in a "stable state" in
other words; we don't try to recover calls that are in the call setup phase.
We need a list of failure modes to know what intermediate states can be
present after a failure.

We discussed failure of supplementary services H.450.  We need to ask Bob
Callahan to summarize the robustness mechanisms built into the H.450
protocol.

Adding End to end ACKs for H.323

We discussed the possibility of adding end-to-end ACKs for all messages in
order to increase the reliability of H.323 and discover that there has been
a failure sooner.  Annex E defines link-by-link acknowledgements, but not
end to end.

SCTP (Simple Control Transmission Protocol)
(http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-07.txt)

Randy Stewart gave a summary of the differences between SCTP and TCP.

        1)      SCTP setup takes one round trip time whereas TCP takes one
and a half round trips.

        2)      SCTP is aware of multi-homing and can handle congestion.  It
supports network-level fault tolerance through multi-homing at either or
both ends of an association.  The design of SCTP includes appropriate
congestion avoidance behavior and resistance to flooding and masquerade
attacks.

        3)      SCTP gets around TCP's head of line blocking by using a
stream mechanism.  For example, in TCP if messages 1, 2 and 3 are sent and 1
gets lost, then 2 and 3 are held up while 1 is retransmitted.  SCTP allows 2
and 3 to be delivered without waiting for 1.; supports sequenced delivery of
user messages within multiple streams, with an option for order-of-arrival
delivery of individual user messages.

        4)      TCP takes 3-4 minutes to discover a failure and this is too
long; SCTP discovers failures more quickly.

        5)      In Randy's performance tests of TCP versus SCTP, SCTP
performed equal to TCP or better.

The status of SCTP is that it is about to become an RFC.  The IETF is
interested in adoption of SCTP for HTTP and AAA.

DDP (Distributed Data protocol)
http://www.ietf.org/internet-drafts/draft-xie-stewart-sigtran-ddp-00.txt

>From the IETF internet-draft abstract:

"Data Distribution Protocol (DDP) provides a fault tolerant data transfer
mechanism over IP networks. DDP uses a name-based addressing model which
isolates a logical communication endpoint from its IP address(es), thus
effectively eliminating the binding between the communication endpoint and
its physical IP address(es) which normally constitutes a single point of
failure.

In addition, DDP defines each logical communication destination as a named
group, providing full transparent support for server-pooling and load
sharing. It also allows dynamic system scalability - members of a server
pool can be added or removed at any time without interrupting the service.

DDP is designed to take full advantage of the network level redundancy
provided by the Simple Transmission Control Protocol (SCTP). But it can also
use other transport protocol like TCP."

We discussed the use of DDP with H.323, for example, the case where there
would be a server pool of gatekeepers.  We discussed the handling of state
information in failure scenarios.  Using DDP, the H.323 application layer
will only need to determine what state information needs to be saved in case
of failure, where that information should be stored and how to get it to the
right place after the failure occurs.  This provides a clean interface
between the application layer and the DDP protocol.

The decisions would be as follows:

        1)      What points (states) to fall back to.
        2)      When and where to checkpoint
        3)      How to reconstruct state from check pointed state
information

The DDP protocol allows the specification of policies for several different
server pool types including:

Round robin
% of load (load balancing)
primary -- backup

The group will review the SCTP and DDP and discuss these in our next
teleconference.



-- maureen

Maureen Stillman
Member of Scientific Staff             Voice: (607)273-0724 x62
IP Voice Networks                       Fax: (607)275-3610
127 W. State Street                     Mobile: (607)227-2933
Ithaca, NY 14850
e-mail: maureen.stillman at nokia.com
www.nokia.com



More information about the sg16-avd mailing list