2.1.12 Transaction Internet Protocol (tip)

NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 11-Mar-98

Chair(s):

Jim Lyon <jimlyon@microsoft.com>
Keith Evans <keith@loc252.tandem.com>

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Harald Alvestrand <Harald.Alvestrand@maxware.no>

Applications Area Advisor:

Harald Alvestrand <Harald.Alvestrand@maxware.no>

Mailing Lists:

General Discussion:tip@tandem.com
To Subscribe: listserv@tandem.com
In Body: in message body: subscribe tip
Archive:

Description of Working Group:

The task of the TIP working group is to develop an Internet standard two-phase commit protocol specification, to enable heterogeneous Transaction Managers to agree on the outcome of a distributed transaction, based upon the Internet-Draft TIP protocol specification <draft-lyon-itp-nodes-01.txt. [Note that since <draft-lyon-itp-nodes-01.txt references a modified version of the Session Control Protocol (SCP), the TIP WG will also be responsible for progression of SCP to Proposed Internet Standard.]

In many applications where different nodes cooperate on some work, there is a need to guarantee that the work happens atomically. That is, each node must reach the same conclusion as to whether the work is to be completed (committed or aborted), even in the face of failures. This behavior is achieved via the use of distributed transactions, employing a two-phase commit protocol (2-pc). The use of distributed transactions greatly simplifies distributed applications programming, since the number of possible outcomes is reduced from many to two, and failure recovery is performed automatically by the transaction service (Transaction Manager).

Key requirements to be met are, 1) the 2-pc protocol be independent of the application-to-application communications protocol, such that it may be used with any application protocol (especially HTTP), and 2) the 2-pc protocol be simple to implement and have a small working footprint (to encourage ubiquitous implementation and offer wide applicability).

The first work item of the group is to develop a requirements document, which describes at least one complete scenario in which the TIP protocol is intended to be used, and describes the requirements on the protocol with regards to:

- Simplicity - Overhead/Performance - Security

The protocols developed by this working group will be analyzed for potential sources of security breach. Identified threats will be removed from the protocol if possible, and documented and guarded against in other cases.

The Internet-Draft document <draft-lyon-itp-nodes-01.txt is to be used as the input base document for the development of this 2-pc protocol specification.

Due to extreme differences in the approach, the group will not consider the CORBA OTS specification as a solution to its requirements.

Goals and Milestones:

Jul 97

  

Submit Versions 2 of the Session Control Protocol (SCP) document as an Internet-Draft.

Jul 97

  

Solicit comments on TIP and SCP Internet-Drafts.

Aug 97

  

Resolve all comments received on TIP and SCP Internet-Drafts, and submit revisions.

Aug 97

  

Meet at Munich IETF.

Sep 97

  

Submit updated versions ofd TIP, SCP, and Requirements Document as Internet-Drafts.

Oct 97

  

Submit final version of TIP and SCP to IESG for consideration as Proposed Standards. Also submit requirements document for consideration as an Informational RFC.

Internet-Drafts:

No Request For Comments

Current Meeting Report

Minutes of the Transaction Internet Protocol (tip) Working Group

Chair(s):

Jim Lyon <jimlyon@microsoft.com>
Keith Evans <keith.evans@tandem.com>

Applications Area Director(s):

Keith Moore <moore+iesg@cs.utk.edu>
Harald Alvestrand <Harald.Alvestrand@maxware.no>

Mailing Lists:

General Discussion: tip@lists.tandem.com
To Subscribe: listserv@lists.tandem.com
In Body: subscribe tip <full name>
Archive:

Description of Working Group:

The task of the TIP working group is to develop an Internet standard two-phase commit protocol specification, to enable heterogeneous Transaction Managers to agree on the outcome of a distributed transaction, based upon the Internet-Draft TIP protocol specification.

In many applications where different nodes cooperate on some work, there is a need to guarantee that the work happens atomically. That is, each node must reach the same conclusion as to whether the work is to be completed (committed or aborted), even in the face of failures. This behavior is achieved via the use of distributed transactions, employing a two-phase commit protocol (2pc). The use of distributed transactions greatly simplifies distributed applications programming, since the number of possible outcomes is reduced from many to two, and failure recovery is performed automatically by the transaction service (Transaction Manager).

Key requirements to be met are: 1) the two-pc protocol be independent of the application-to-application communications protocol, such that it may be used with any application protocol (especially HTTP), and 2) the two-pc protocol be simple to implement and have a small working footprint (to encourage ubiquitous implementation and offer wide applicability).

The first work item of the group is to develop a requirements document, which describes at least one complete scenario in which the TIP protocol is intended to be used, and describes the requirements on the protocol with regards to:

- Simplicity
- Overhead/Performance
- Security

The protocols developed by this working group will be analyzed for potential sources of security breach. Identified threats will be removed from the protocol if possible, and documented and guarded against in other cases.

The TIP Internet-Draft document is to be used as the input base document for the development of this 2-pc protocol specification.

Due to extreme differences in the approach, the group will not consider the CORBA OTS specification as a solution to its requirements.

Goals and Milestones:

Jul 97 Submit Version 2 of the Session Control Protocol (SCP) document as an Internet-Draft.
Jul 97 Solicit comments on TIP and SCP Internet-Drafts.
Aug 97 Resolve all comments received on TIP and SCP Internet-Drafts, and submit revisions.
Aug 97 Meet at Munich IETF.
Sep 97 Submit updated versions of TIP, SCP, and Requirements document as Internet-Drafts.
Oct 97 Submit final version of TIP and SCP to IESG for consideration as Proposed Standards. Also submit Requirements document for consideration as an Informational RFC.

Internet-Drafts:

Transaction Internet Protocol <draft-lyon-itp-nodes-06.txt>.
Transaction Internet Protocol - Requirements & Supplemental Information <draft-evans-tip-functions-02.txt>.
Using the Transaction Internet Protocol with HTTP <draft-ietf-tip-usehttp-01.txt>.

Current Meeting Report

Minutes of the Transaction Internet Protocol Working Group

Reported by: Keith Evans

The meeting convened with an update from Harald A. regarding the status of the requested advance of the current TIP I-Ds to IETF standards track. Harald stated that the TIP protocol I-D will be advanced as a proposed standard and the supplemental I-D will be published as an informational RFC.

We will not produce another version of the I-D to include the change to the IDENTIFY command (reverse order of 1ary and 2ndary TM URLs), since the change is marginal and we do not wish to delay the progression of TIP onto the standards track.

The remainder of the meeting was spent discussing possible future extensions to the TIP protocol. Keith gave a presentation describing these extensions (acknowledged commit, redirection, synchronization - see separate presentation material). It was felt that the first two of these were clear enough and worth proceeding with, but synchronization should be left until more usage experience with TIP has been obtained.

The matter then became via what process should TIP be further developed? Harald stated that the current charter of the wg has been fulfilled by the advance of the current specifications onto the standards track. He said that further development should occur via individual contribution and discussion on the mailing list (which will be maintained), there is no need to further perpetuate the WG itself. Keith will circulate the description of the acknowledged commit and redirection enhancements on the mailing list. If there is a positive response then a new I-D can be submitted (as a compatible update to the RFC version).

The final subject of discussion was the use of TIP with HTTP I-D. There has been very little comment on this document (which Harald would like to see published as an informational RFC). A number of people volunteered to read the specification and submit comments to the TIP mailing list, within one week. Once these comments have been resolved we can determine how to proceed with this document. [note that all comments are welcome - not just those from people present at the meeting, please try to read the document and submit comments by 4/9/98].

And so the TIP Working Group closed.

Slides

TIP - Agenda

Attendees List

go to list