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@nokia.com Sasha Ruditsky sasha@tlv.radvision.com Paul Jones paul.jones@ties.itu.int Randy Stewart rstewar1@email.mot.com Qiaobing Xie xieqb@cig.mot.com Terry Anderson tla@lucent.com Timothy Sipsey Timothy.Sipsey@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@nokia.com www.nokia.com