Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/tip/tip-minutes-97aug.txt

Text File | 1997-10-11 | 14.1 KB | 354 lines

Transaction Internet Protocol (tip)

Chair(s):

Jim Lyon <[e-mail]>
Keith Evans <[e-mail]>

Applications Area Director(s):

Keith Moore <[e-mail]>
Harald Alvestrand <[e-mail]>

Mailing Lists:

General Discussion: [e-mail]
To Subscribe: [e-mail]
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
    <protocol-identifier>. 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 <protocol-identifier>.
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--