Re: TCP for Transaction (T/TCP) protocol
Mohsen BANAN-Public <public@mohsen.banan.1.byname.net> Mon, 15 January 2001 20:07 UTC
Received: by ietf.org (8.9.1a/8.9.1a) id PAA14892 for ietf-outbound.10@ietf.org; Mon, 15 Jan 2001 15:07:33 -0500 (EST)
Received: from rostam.neda.com ([198.62.92.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14509 for <ietf@ietf.org>; Mon, 15 Jan 2001 14:47:37 -0500 (EST)
Received: (from mohsen@localhost) by rostam.neda.com (8.9.1/8.9.1) id LAA29056; Mon, 15 Jan 2001 11:28:05 -0800 (PST)
Date: Mon, 15 Jan 2001 11:28:05 -0800
Message-Id: <200101151928.LAA29056@rostam.neda.com>
MIME-Version: 1.0
From: Mohsen BANAN-Public <public@mohsen.banan.1.byname.net>
To: L.Wood@eim.surrey.ac.uk, Hung Pham <hpham@nortelnetworks.com>, ietf@ietf.org
Subject: Re: TCP for Transaction (T/TCP) protocol
In-Reply-To: <Pine.GSO.4.21.0101122018330.26692-100000@regan.ee.surrey.ac.uk>
References: <3A5F4C05.2253150D@americasm01.nt.com> <Pine.GSO.4.21.0101122018330.26692-100000@regan.ee.surrey.ac.uk>
X-Mailer: VM 6.33 under 19.15p7 XEmacs Lucid
Content-Type: text/plain; charset="US-ASCII"
X-Loop: ietf@ietf.org
>>>>> On Fri, 12 Jan 2001 13:25:09 -0500, "Hung Pham" <hpham@nortelnetworks.com> said: >>>>> On Fri, 12 Jan 2001 20:25:39 +0000 (GMT), Lloyd Wood <l.wood@eim.surrey.ac.uk> 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 addresses do not justify the cost of implementing it. RDP allows for many options and selections, which makes its use difficult. Various lessons can be learned from why RTP has not been widely adopted. 2.6 VMTP --------- Versatile Message Transaction Protocol (VMTP) is specified in [9]. VMTP can be considered to be a specialized transport protocol, targeted for what it calls the transaction model of communications. One of the reasons why VMTP has not been heavily used is because it tries to address too broad of a software engineering-centric model. VMTP allows for many options and selections, which makes its use difficult. Various lessons can be learned from why VMTP has not been widely adopted. 2.7 TCP -------- Transmission Control Protocol (TCP) is specified in [22] and [6]. TCP is mature, well understood and stable. Congenstion control and flow control mechanisms for TCP have been developed over the years, and incorporated into TCP implementations. The simplest and shortest TCP interaction involves 5 PDU exchanges. For applications wishing to accomplish short and occasional communications in less than 5 PDU exchanges, ESRO is more efficient that TCP. 2.8 UDP -------- UDP (User Datagram Protocol) is specified in [21]. UDP is a very simple and thin layer on top of IP, which does not provide reliability or sequence ordering. Applications requiring a reliable connectionless transport need to build on top of UDP. ESRO provide an efficient and reliable transport service on top of UDP. 2.9 UDP Plus Ad Hoc Re-Transmissions ------------------------------------- Various protocols have added their own specific re-transmission policies on top of UDP to make it more reliable. Examples of such efforts include the Domain Name System (DNS) [13] [14], Network Time Protocol (NTP) [12], and NNTP for Usenet News Reading. These efforts have all resulted in incomplete and limited solutions. The problems with such approaches were understood as early as 1985 [4]. References ========== [1] WAP Wireless Transaction Protocol Specification, February 2000. The WAP-201-WTP article available at http://www.wapforum.org/what/technical.htm. [2] M. Banan. Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 1.3. Request for Comments (Informational) 2524, Neda Communications, Inc., February 1999. Online document is available at ftp://ftp.isi.edu/in-notes/rfc2524.txt. [3] M. Banan, J. Cheng, and M. Taylor. AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2. Request for Comments (Informational) 2188, Neda Communications, Inc., September 1997. Online document is available at ftp://ftp.isi.edu/in-notes/rfc2188.txt. [4] B. Braden. Towards a transport service for transaction processing applications. RFC 955, Internet Engineering Task Force, September 1985. [5] B. Braden. Extending TCP for transactions -- concepts. Request for Comments (Informational) 1379, Internet Engineering Task Force, November 1992. [6] B. Braden. T/TCP -- TCP extensions for transactions functional specification. Request for Comments (Experimental) 1644, Internet Engineering Task Force, July 1994. [7] Remote Operations: Model, Notation and Service Definition. The International Telegraph and Telephone Consultative Committee, March 1988. Recommendation X.219. [8] Remote Operations: Protocol Specification. The International Telegraph and Telephone Consultative Committee, March 1988. Recommendation X.229. [9] D. Cheriton. VMTP: versatile message transaction protocol: Protocol specification. Request for Comments (Experimental) 1045, Internet Engineering Task Force, February 1988. [10] B. Hinden and C. Partridge. Version 2 of the reliable data protocol (RDP). Request for Comments (Experimental) 1151, Internet Engineering Task Force, April 1990. [11] B. Hinden and J. Sax. Reliable data protocol. Request for Comments (Experimental) 908, Internet Engineering Task Force, July 1984. (Updated by RFC1151). [12] D. Mills. Network time protocol (v3). Request for Comments (Draft Standard) 1305, Internet Engineering Task Force, April 1992. (Obsoletes RFC1119). [13] P. Mockapetris. Domain names - concepts and facilities. Request for Comments (Standard) STD 13, 1034, Internet Engineering Task Force, November 1987. (Obsoletes RFC882); (Obsoletes RFC883); (Obsoletes RFC973); (Obsoleted by RFC2065); (Updated by RFC1101); (Updated by RFC1876); (Updated by RFC1982); (Updated by RFC2181); (Updated by RFC2308). [14] P. Mockapetris. Domain names - implementation and specification. Request for Comments (Standard) STD 13, 1035, Internet Engineering Task Force, November 1987. (Obsoletes RFC973); (Obsoleted by RFC2136); (Obsoleted by RFC2137); (Updated by RFC1348); (Updated by RFC1995); (Updated by RFC1996); (Updated by RFC2065); (Updated by RFC2181); (Updated by RFC2308). [15] Mohsen Banan. Efficiency Study of EMSD vs. SMTP/POP3/IMAP. Neda Published Document 103-101-01.01, EMSD Organization, 1996. Online document is available at http://www.emsd.org/pubs/biblio/103-101-01_01/index.html. [16] Mohsen Banan. ESROS Application Programming Interface. Neda Published Document 103-101-06.03, ESRO Organization, 1996. Online document is available at http://www.esro.org/pubs/biblio/103-101-06_03/index.html. [17] Mohsen Banan. Lightweight & Efficient Application Protocol (LEAP) Manifesto. FPF Published Document 108-101-01, Free Protocols Foundation, Bellevue, WA, January 2000. Online document is available at http://www.freeprotocols.org/pubs/biblio/108-101-01/index.html. [18] Mohsen Banan. The WAP Trap. FPF Published Document 108-102-01, Free Protocols Foundation, Bellevue, WA, January 2000. Online document is available at http://www.freeprotocols.org/pubs/biblio/108-102-01/index.html. [19] G. Montenegro, S. Dawkins, M. Kojo, V. Magret, and N. Vaidya. Long Thin Networks. Request for Comments (Informational) 2757, The Internet Society, January 2000. Online document is available at ftp://ftp.isi.edu/in-notes/rfc2757.txt. [20] Information Processing Systems --- Open Systems Interconnection: Basic Reference Model. International Organization for Standardization and International Electrotechnical Committee, 1984. Interational Standard 7498. [21] J. Postel. User datagram protocol. Request for Comments (Standard) STD 6, 768, Internet Engineering Task Force, August 1980. [22] J. Postel. Transmission control protocol. Request for Comments (Standard) STD 7, 793, Internet Engineering Task Force, September 1981. (Obsoletes RFC761). [23] R. Srinivasan. Binding protocols for ONC RPC version 2. Request for Comments (Proposed Standard) 1833, Internet Engineering Task Force, August 1995. [24] R. Srinivasan. RPC: remote procedure call protocol specification version 2. Request for Comments (Proposed Standard) 1831, Internet Engineering Task Force, August 1995. [25] R. Srinivasan. XDR: external data representation standard. Request for Comments (Proposed Standard) 1832, Internet Engineering Task Force, August 1995.
- Re: TCP for Transaction (T/TCP) protocol Lloyd Wood
- Zone transfer Henning Schulzrinne
- Re: Zone transfer Randy Bush
- Re: Zone transfer hardie
- TCP for Transaction (T/TCP) protocol Hung Pham
- TCP for Transaction (T/TCP) protocol Garrett Wollman
- Re: Zone transfer Fred Baker
- Re: Zone transfer Henning Schulzrinne
- IETF mailing list archive problems Martin J. Duerst
- Re: IETF mailing list archive problems Donald E. Eastlake 3rd
- Re: IETF mailing list archive problems Rahmat M. Samik-Ibrahim
- Re: TCP for Transaction (T/TCP) protocol Mohsen BANAN-Public