On Fri, 12 Jan 2001 13:25:09 -0500, "Hung Pham" [EMAIL PROTECTED] said:
On Fri, 12 Jan 2001 20:25:39 + (GMT), Lloyd Wood [EMAIL PROTECTED]
said:
Hung Hello;
Hung I'm interested in the "TCP for Transaction or T/TCP" protocol,
Hung basically this protocol collapses the TCP three way handshake to a
Lloyd five-way, if you remember the two at the _end_ of the connection...
Hung single message to reduce latency overhead.
Lloyd while increasing processing load and opening the door further to
Lloyd effective denial-of-service attacks, since buffers must be allocated
Lloyd for data immediately by the receiver before the sender is verified.
The problem domain which T/TCP attempts to address is clearly valid.
However, I agree that T/TCP's approach of being bundled with
TCP is not effective and pragmatic.
There are various other protocols (including ESRO -- RFC-2188)
which address the same problem space as T/TCP. A survey of
these protocols and my assessment of where they fail is
included in the article:
ESRO: A Foundation for the Development of Efficient Protocols
=
available through:
http://www.leapforum.org/LEAP/Manifesto/article/ESROcomponent/one/index.html
The segment related to mention of other protocols in the
reliable RPC (transactions / reliable connectionless
transports) problem space is reproduced below in plain text
format.
Those interested in further discussing this topic are invited
to join the relevant mainling lists at
http://www.esro.org/
and
http://www.leapforum.org/
...Mohsen.
--
2 Other Related Protocols
==
The overall model of ESRO is similar to and consistent with
many existing protocols. The distinguishing characteristic
of ESRO is its efficiency. Also, the scope of ESRO is very
narrow and well defined. The options and selections that
it provides for are few and clear.
A brief comparison of ESRO to other similar protocols is
provided in the sections below.
2.1 RPC
Remote Procedure Call (RPC) is specified in RFC-1831 [24]
and RFC-1833 [23].
The RPC specifications define a remote procedure model that
is essentially the same as ESRO. However, the notation of
RPC uses a syntax which is quite different from that of
ESRO. RPC can rely on a connection-oriented or a
connectionless transport mechanism. When using the
connectionless mechanism, the retransmission and
reliability issues are considered to be beyond the scope of
the RPC specification. RPC is usually used in combination
with External Data Representation, XDR (RFC-1832) [25].
When using RPC over UDP, no meaningful reliable transport
mechanism is defined. For this reason use of RPC over UDP
has been limited to LANs.
2.2 ROSE
-
Remote Operations Services Element (ROSE) is specified in
[7] and [8]. ROSE is a complete and heavyweight
traditional OSI application which assumes availability of
all of the underlying OSI layers. The ESRO protocols can
accomplish short operations with much less overhead than
ROSE.
2.3 WAP's WTP
--
The Wireless Appliction Protocol (WAP) includes a layer
which is similar to ESRO, called ``Wireless Transaction
Protocol'' (WTP) [1]. The WTP specification was published
after ESRO was published, and is similar in functionality
to ESRO. In many ways WTP can be considered to be patterned
after ESRO; however, WTP is in fact a step backwards.
The clear and simple Remote Operations model of ESRO is
renamed as ``Wireless Transactions'' in an inappropriate
context. The notation specification conventions are not
used, and the state machines are not as robust.
More importantly, the WTP specifications are not stable,
have not been published as Internet RFCs, and have not been
declared to be patent free.
As early as 1995, those involved in the development of WTP
were made aware of LSROS and ESRO. The only reason we know
of for their re-specification of WTP, rather than re-use of
ESRO, is the WAP Forum's desire for control. More details
on the problems of the WAP Forum's approach are provided in
the article The WAP Trap [18].
2.4 T/TCP
--
Transaction/TCP is specified in [5] and [6]. T/TCP is a
backwards-compatible extension of TCP which provides
efficient transaction-oriented service in addition to
virtual-circuit service. Use of T/TCP often involves
replacing existing TCP implementations. This
non-evolutionary aspect of T/TCP is one of the reasons why
T/TCP has not been widely adopted.
Various lessons can be learned from why T/TCP has not been
widely adopted.
2.5 RDP
Reliable Data Protocol (RDP) is specified in [11] and [10].
RDP can be considered to be a specialized TCP, specified
for particular circumstances in which some of TCP's
facilities are needed. One of the reasons why RDP has not
been heavily used is because the set of specialized
circumstances that it addr
