Transaction Internet Protocol (tip) Chair(s): Jim Lyon Keith Evans Applications Area Director(s): Keith Moore Harald Alvestrand Mailing Lists: General Discussion: tip@tandem.com To Subscribe: listserv@tandem.com In 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 . 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 behaviour 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 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 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. - Transaction Internet Protocol - Requirements. - Session Control Protocol. Current Meeting Report Minutes of the Transaction Internet Protocol Working Group Reported by: Keith Evans Discussion of TIP Requirements I-D: Peter Furniss raised a question re the "frequency" of TIP usage. i.e. is the requirement that TIP be used for infrequent transactional application interaction only (e.g. a few transactions per hour), or more? The requirements I-D states that TIP is intended to be applicable for all transactional application needs, both low and high demand, on intranets as well as the internet. The TIP multiplexing and pipelining features were added specifically to ensure that TIP could meet high-throughput requirements. But there is no reason why TIP cannot be used for low-end applications either. Rudiger Wiehler asked why is another low-end 2-pc protocol required, when there are already many, and interoperability is achieved via gateways? A number of reasons were given: - most existing 2-pc protocols are proprietary and there are no gateways between them (with the exception of a very few for LU6.2 Synclevel 2). - gateways restrict interoperability to only the (two) 2pc protocols mapped by the gateway, and do not therefore provide for general interoperability. - existing 2-pc protocols may only be used with specific application protocols. - standard 2-pc protocol solutions are heavyweight and complex (and hence are not widely implemented). RW accepted this, but then asked about further issues pertaining to general electronic commerce that TIP does not address. e.g. there is a need for non-repudiation (some form of legally binding contract between the client and server). It was agreed that this is so. TIP however is not intended to provide a solution to all issues re electronic commerce. It does provide a first step in support for transactions, and does not preclude the definition of further protocols to meet the needs for general electronic commerce. A note to this effect will be added to the Requirements I-D. Solutions for general electronic commerce should become the subject of IETF activity once the requirements are better understood. RW asked why in the example does the travel agency perform the transaction coordinator role, as opposed to some independent 3rd-party? The example is just an example, and there is no reason why alternative configurations could not be built (such as the type Rudiger suggested). A note to this effect will be added to the Requirements I-D. PF thought the lack of support for commit from anywhere is a negative, and ought to be added. Johannes Klein noted that TIP sort of provides this capability already in that the coordinator node may be chosen by the application at the start of the transaction (via use of BEGIN). Many other 2-pc protocols do not support commit from anywhere. Given that TIP is intended to be simple to implement , it was felt this feature adds too much complexity for the first release, but it could be added later (if there was sufficient demand). PF asked what is the point of COMMIT in Enlisted state? This is straightforward 1-pc. PF asked whether this could be enhanced to support the "last-agent" optimisation? It could, but the argument is the same as commit from anywhere, they both require support for coordinator migration which adds too much complexity for the first release. [A note should be added to the Protocol I-D clarifying that COMMIT in Enlisted state is 1-pc, and that it should only be used when the local TIP TM has no recoverable resources, and only one subordinate (since the sender will not be involved in any transaction recovery process).] Tom Freund asked whether TIP supports the CORBA OTS transaction-factory concept? It does: a client can use BEGIN to get a transaction from somewhere (a transaction factory), and pass the TIP URL returned on subsequent application requests (thereby propagating the transaction, with the transaction-factory as the root). Paul Skaistis noted that the Requirements I-D states the TIP protocol itself be useable with transports other than TCP/IP. He suggested the Protocol I-D be updated to state that nothing precludes the use of TIP with other transports, but that the protocol is specified only in terms of TCP/IP, and it is up to the implementor to ensure whatever transport is chosen has the necessary semantics, and to map the TIP protocol appropriately. This was agreed. It was pointed out that references in both the Requirements and Protocol I-Ds to "Secure Socket Layer", should be changed to "Transport Layer Security". Requirements I-D, Section TIP Requirements, Item #6 (Security), 1st sentence, change "SSL should", to "TLS may". It was agreed a new requirement should be added to the Requirements I-D, that the TIP protocol be extensible. The Requirements I-D should also include an example where PUSH is used. Discussion of TIP Protocol and SCP I-Ds: It was asked why use SCP, rather than a "connection tag" on the TIP protocol itself? Really thats all the SCP header is in any case, so lets leave well enough alone. It was agreed that progressing SCP as a separate generalised multiplexing protocol I-D would be problematic - so the SCP I-D will be renamed ("the TIP Mulitplexing Protocol"), and included as an addendum to the TIP Protocol I-D itself, for use only with TIP. If and when a generalised multiplexing protocol comes along, we can look at whether TIP can be respecified to work with it. We also need to update the Protocol I-D to state that a TIP command is wholly contained within a single SCP message. RW asked whether it was true that TIP allowed a client to be told under certain failure conditions that a transaction had aborted, when in fact it had committed? It is true that a client application could fail to receive notification of the outcome of a transaction (if the application dies during the commit process for example). In this case its up to the application to determine the outcome via some private means. This is a problem common to all transaction systems, and in no way exacerbated by TIP. TIP does not include anything which would cause the protocol to return committed when the transaction is known to have aborted. PF suggested that the "node rules" stated in his 8/7/97 e mail to the TIP mailing list be included in the Protocol I-D (these rules provide information regarding what a TIP TM and participant resource managers must do in terms of maintaining recoverable state etc). It was discussed how much of this should be included in the I-D itself versus the existing references to other works (these rules are no different for TIP, and are well covered in other documents). It was agreed to add the suggested text to the recovery section of the Requirements I-D. RW raised the issue that since TIP does not provide a means to specify a "global" transaction identifier, all branches of a TIP transaction must be treated as loosely coupled (RM locks are not shared, and transaction deadlocks may occur). It was agreed to add text to this effect in the Protocol I-D, and also state that deadlock detection is normally achieved via some sort of local timeout mechanism. It was also agreed that we need to add a placeholder for future support of global transaction identifiers. The details of this are still to be determined. PF raised in an e-mail the issue that a TM may be in no state to respond when it receives a RECONNECT or QUERY command (e.g. if its log is unavailable). So, a "try later" or somesuch reply is required in these cases. PS said why doesnt the receiver just wait, or drop the SCP connection? This issue is still to be resolved. Questions arose which suggest it may be useful to publish a hypothetical API provided by a TIP TM. This would be useful for describing example applications, and may help implementation. This could be added to the Requirements I-D (which is intended to be published as an informational RFC when TIP becomes a standard). Text should be added to the Protocol I-D that a TIP TM should not PULL the same transaction twice. i.e. it should just respond "ok" to the application pull request, and not send a PULL command. Add text to the Protocol I-D that a TIP connection (TCP or SCP if multiplexing is being used), returns to its original polarity when Idle state is reached. PF suggested it would be very useful to describe how TIP is used with specific "popular" application protocols (e.g. as an OTS transaction context object, or HTTP). It was agreed that this should be done once TIP becomes available and typical usage scenarios are apparent. Wrap-up: It was agreed that the list of editorial changes to the TIP I-Ds noted previously to this meeting (via various e-mails) would be summarised and added to these minutes (see below). These and the changes agreed at the meeting (as described here), will be made to the next versions of the TIP I-Ds. The WG assented that these next versions should therefore represent complete, credible specifications, and require only minor further modification (if any) before being recommended for standard status. Changes Previously Discussed via E-mail: All changes are to the Protocol I-D unless otherwise stated. [Note that if an item is missing here, its because its either covered above, or already addressed in the Requirements I-D.] 1. Add a simple picture showing the 2-pipe nature of TIP. 2. Better distinguish whether a command/state relates to a transaction or a connection. 3. In "Command Pipelining", no command can be pipelined after IDENTIFY as the version of the protocol has not yet been negotiated. Delete from the example. 4. In "Commands" under MULTIPLEX, Para 3, the multiplex protocol can't take over the connection until the response is received as it is not known if the remote node supports the protocol in the parameter . Add text clarifying this. 5. In "States of a connection" for the "prepared" state, the commands which are allowed should be added for consistency with the specification of other states, e.g., "enlisted". 6. In "Commands and Responses", first para, second sentence, delete the words "each word is" and change "are" to "is". 7. In "Commands" under MULTIPLEX, the parameter should be . 8. In "Commands" under the response PUSHED, first sentence, add the word "the" after "and". 9. In "Commands" under the response PUSHED, second sentence, add the word "transaction" after the word "current". 10. In "Connection Failure", the first sentence needs clarification. 11. Add text that an application should not call commit until all outstanding replies are received (Requirements I-D). 12. In "Commands", it would be useful to specify where it is necessary to wait for a response and where pipelining can be used, e.g. with Begin. 13. In "Commands" under IDENTIFY, it is assumed that all versions of protocol from the lowest to the highest are implemented - state this explicitly. 14. Clarify that the party which initiates the VIRTUAL connection is the primary on that virtual connection. 15. Change command/response value range to ASCII 32 - 126. 16. Fix page numbering. 17. Update ref[2] (HTTP). ------=_NextPart_000_01BCB14D.53B573D0--