draft-csapuntz-tcpmsgbnd

Last Version:	draft-csapuntz-tcpmsgbnd-00.txt		Tracker Entry
Date:	23-Jun-2001
Disposition:	removed

INTERNET-DRAFT                                          C. Sapuntzakis
                                                         Cisco Systems
<draft-csapuntz-tcpmsgbnd-00.txt>                          August 2000
Expires February 2001

                      TCP Message Boundary Option


Status of this Memo

     This document is an Internet-Draft and is in full conformance with
     all provisions of Section 10 of RFC2026.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups.  Note that
     other groups may also distribute working documents as Internet-
     Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other docu¡
     ments at any time.  It is inappropriate to use Internet-Drafts as
     reference material or to cite them other than as "work in
     progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.


Copyright Notice

     Copyright (C) Cisco Systems (2000). All Rights Reserved.


Abstract


     TCP does not have a mechanism for specifying message boundaries in
     a stream. This I-D describes a new TCP option and a new way of
     using the TCP urgent field to specify message boundaries in the
     stream.








Sapuntzakis                                                     [Page 1]

Internet-Draft         TCP Message Boundary option        29 August 2000


Introduction


     TCP does not have a built-in mechanism for signalling message
     boundaries at the TCP layer.

     Most current TCP message encapsulations place the message length at
     the beginning of each message. The message length serves to delin¡
     eate the end of the current message as well as the beginning of the
     next message.

     Unfortunately, when relying solely on this scheme, missing a seg¡
     ment with a message length makes it impossible to find message
     boundaries in subsequent segments. The missing segment must be
     received before later segments can be parsed and processed.

     There are several ways to get around this.


     * Make each message fixed size
     * Put synchronization information in the stream at fixed intervals
     * Use a marker byte to mark message boundaries


     However, none of these techniques seems particularly appetizing.
     Marker bytes work well for hardware but the escape sequences they
     assume make it difficult for software. Putting information at fixed
     intervals in the stream does not prevent the information from being
     split across segments.

     Instead, this document proposes a combination of a TCP option and
     an overloaded usage of the urgent field in the TCP header.

     This option brings TCP more in-line with the principles of applica¡
     tion-layer framing outlined in [ALF].


.  Message boundary option


1.1.  Usage


     This TCP option appears only during negotiation. It is a two byte
     option, with kind <fill in here> and length 2. If both sides indi¡
     cate support for the TCP message boundary option, then the URG bit
     is interpreted as below.




Sapuntzakis                                                     [Page 2]

Internet-Draft         TCP Message Boundary option        29 August 2000


.  Redefinition of the URG bit and


     The URG bit and urgent pointer are redefined from RFC 793. An URG
     bit set to one in a segment indicates that the urgent pointer is
     valid.

     The sum of the urgent pointer and sequence number of the TCP seg¡
     ment yields the sequence number of the first byte of an applica¡
     tion-layer message.


.  Security considerations


     A malicious interceptor could modify the message boundary informa¡
     tion, falsely indicating message boundaries and corrupting the
     stream. However, such an interceptor could probably manipulate the
     stream to corrupt it in other ways.
































Sapuntzakis                                                     [Page 3]

Internet-Draft         TCP Message Boundary option        29 August 2000


.  Authors' Addresses



     Constantine Sapuntzakis
     Cisco Systems, Inc.
     170 W. Tasman Drive
     San Jose, CA 95134
     USA

     Phone: +1 408 525 5497
     Email: csapuntz@cisco.com




.  References


     [ALF] D. D. Clark and D. L. Tennenhouse, "Architectural considera¡
     tions for a new generation of protocols," in SIGCOMM Symposium on
     Communications Architectures and Protocols , (Philadelphia, Penn¡
     sylvania), pp. 200--208, IEEE, Sept. 1990.  Computer Communications
     Review, Vol. 20(4), Sept. 1990.

     [TCP]  Postel, J., "Transmission Control Protocol - DARPA Internet
     Program Protocol Specification", RFC 793, September 1981



     Expires February 2001




















Sapuntzakis                                                     [Page 4]