The Transport Layer: Tutorial and Survey
`SAMI
`IREN and PAUL D. AMER
`
`University of Delaware
`AND
`PHILLIP T. CONRAD
`
`Temple University
`
`Transport layer protocols provide for end-to-end communication between two or
`more hosts. This paper presents a tutorial on transport layer concepts and
`terminology, and a survey of transport layer services and protocols. The transport
`layer protocol TCP is used as a reference point, and compared and contrasted with
`nineteen other protocols designed over the past two decades. The service and
`protocol features of twelve of the most important protocols are summarized in both
`text and tables.
`
`Categories and Subject Descriptors: C.2.0 [Computer-Communication
`Networks]: General—Data communications; Open System Interconnection
`Reference Model (OSI); C.2.1 [Computer-Communication Networks]: Network
`Architecture and Design—Network communications; Packet-switching networks;
`Store and forward networks; C.2.2 [Computer-Communication Networks]:
`Network Protocols; Protocol architecture (OSI model); C.2.5 [Computer-
`Communication Networks]: Local and Wide-Area Networks
`General Terms: Networks
`Additional Key Words and Phrases: Congestion control, flow control, transport
`protocol, transport service, TCP/IP
`
`1. INTRODUCTION
`
`In the OSI 7-layer Reference Model, the
`transport layer is the lowest layer that
`operates on an end-to-end basis be-
`tween two
`or more
`communicating
`hosts. This layer lies at the boundary
`between these hosts and an internet-
`
`work of routers, bridges, and communi-
`cation links that moves information be-
`tween hosts. A good transport layer
`service (or simply, transport service) al-
`lows applications to use a standard set
`of primitives and run on a variety of
`networks without worrying about differ-
`ent network interfaces and reliabilities.
`
`This work was supported, in part, by the National Science Foundation (NCR 9314056), the U.S. Army
`Research Office (DAAL04-94-G-0093), and the Adv Telecomm/Info Dist’n Research Program (ATIRP)
`Consortium sponsored by ARL under Fed Lab Program, Cooperative Agreement DAAL01-96-2-0002.
`Authors’ addresses: S. Iren and P. D. Amer, Department of Computer and Information Sciences,
`University of Delaware, Newark, DE 19716; P. T. Conrad, Department of Computer and Information
`Sciences, Temple University, Philadelphia, PA 19122.
`Permission to make digital / hard copy of part or all of this work for personal or classroom use is granted
`without fee provided that the copies are not made or distributed for profit or commercial advantage, the
`copyright notice, the title of the publication, and its date appear, and notice is given that copying is by
`permission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to
`lists, requires prior specific permission and / or a fee.
`© 2000 ACM 0360-0300/99/1200–0360 $5.00
`
`ACM Computing Surveys, Vol. 31, No. 4, December 1999
`
`Petitioners' Exhibit 1017
`Page 0001
`
`

`

`CONTENTS
`
`1. Introduction
`2. Transport Layer Concepts and Terminology
`2.1 Introduction to TCP
`2.2 General Role of the Transport Layer
`2.3 Terminology: SDUs, PDUs, and the like
`2.4 Example TCP Connection, Step-by-Step
`2.5 What this example shows. . . and does not show
`3. Transport Service
`3.1 CO-message vs. CO-byte vs. CL
`3.2 Reliability
`3.3 Blocking vs. Non-Blocking
`3.4 Multicast vs. Unicast
`3.5 Priority vs. No-priority
`3.6 Security vs. No-security
`3.7 Status-reporting vs. No-status-reporting
`3.8 Quality-of-service vs. No-quality-of-service
`4. Transport Protocol Features
`4.1 Connection-oriented vs. Connectionless
`4.2 Transaction-oriented
`4.3 CO Protocol Features
`4.4 Error Control: Sequence Numbers, Acks, and
`Retransmissions
`4.5 Flow/Congestion Control
`4.6 Multiplexing/Demultiplexing
`4.7 Splitting/Recombining
`4.8 Concatenation/Separation
`4.9 Blocking/Unblocking
`4.10 Segmentation/Reassembly
`5. Transport Protocol Examples
`5.1 UDP
`5.2 TP4
`5.3 TP0
`5.4 NETBLT
`5.5 VMTP
`5.6 T/TCP
`5.7 RTP
`5.8 APPN (SNA)
`5.9 NSP (DECnet)
`5.10 XTP
`5.11 SSCOP/AAL5 (ATM)
`5.12 Miscellaneous Transport Protocols
`6. Future Directions and Conclusion
`6.1 Impacts of Trends and New Technologies
`6.2 Wireless Networks
`6.3 Debates
`6.4 Final Observations
`APPENDIX
`
`Essentially, the transport layer isolates
`applications from the technology, de-
`sign, and idiosyncracies of the network.
`Dozens of transport protocols have
`been developed or proposed over the last
`two decades. To put this research in
`perspective, we focus first on the fea-
`tures of probably the most well-known
`transport protocol — namely the Inter-
`net’s Transmission Control Protocol
`
`Transport Layer
`
`•
`
`361
`
`(TCP) — and then contrast TCP with
`many alternative designs.
`Section 2 introduces the basic con-
`cepts and terminology of the transport
`layer through a simple example illus-
`trating a TCP connection. Section 3 sur-
`veys the range of different services that
`can be provided by a transport layer.
`Similarly, Section 4 surveys the range
`of protocol designs that provide these
`services. (The important distinction be-
`tween service and protocol is a major
`theme throughout this paper.) Section 5
`briefly surveys nine widely imple-
`mented transport protocols other than
`TCP (UDP, TP0, TP4, SNA-APPN,
`DECnet-NSP, ATM, XTP, T/TCP and
`RTP) and two others that, although not
`widely implemented, have been particu-
`larly influential (VMTP and NETBLT).
`This section also includes briefer de-
`scriptions of eight experimental proto-
`cols that appear in the research litera-
`ture (Delta-t, MSP, SNR, DTP, k-XP,
`TRUMP, POC, and TP11). Section 6
`concludes the paper with an overview of
`past, current, and future trends that
`have influenced transport layer design
`including the impact of wireless net-
`works. This section also presents a few
`of the debates concerning transport pro-
`tocol design. As an appendix, tables are
`provided summarizing TCP and eleven
`of the transport protocols discussed in
`Section 5. Similar tables for the experi-
`mental protocols are omitted for reasons
`of space, but are available on the au-
`thors’ Web site: www.eecis.udel.edu/
`˜amer/PEL/survey/.
`This survey concentrates on unicast
`service and protocols — that is, commu-
`nication between exactly two hosts (or
`two host processes). Multicast protocols
`[Armstrong et al. 1992; Bormann et al.
`1994; Braudes and Zabele 1993; Deer-
`ing 1989; Floyd et al. 1995; McCanne et
`al. 1996; Smith and Koifman 1996] pro-
`n $ 2
`vide
`communication
`among
`hosts. Multicast represents an impor-
`tant research area currently undergoing
`significant
`change and development,
`and is worthy of a separate survey.
`
`ACM Computing Surveys, Vol. 31, No. 4, December 1999
`
`Petitioners' Exhibit 1017
`Page 0002
`
`

`

`362
`
`•
`
`S. Iren et al.
`
`study surveying eight
`A previous
`transport protocols can be found in Do-
`eringer et al. [1990].
`
`2. TRANSPORT LAYER CONCEPTS AND
`TERMINOLOGY
`
`From an application programmer’s per-
`spective, the transport layer provides
`interprocess
`communication between
`two processes that most often are run-
`ning on different hosts. This section in-
`troduces some basic transport layer con-
`cepts and terminology
`through an
`example: a simple document retrieval
`over the World Wide Web (herein Web)
`utilizing the TCP transport protocol.
`
`2.1 Introduction to TCP
`
`Although we provide a broad survey of
`the transport layer, the service and pro-
`tocol features of TCP are used through-
`out this paper as a point of reference.
`Over the last two decades the Inter-
`net protocol
`suite
`(also
`called the
`TCP/IP protocol suite) has come to be
`the most ubiquitous form of computer
`networking. Hence,
`the most widely
`used transport protocols today are TCP
`and its companion transport protocol,
`the User Datagram Protocol (UDP). A
`few other protocols are widely used,
`mainly because of their connection to
`the proprietary protocol suites of partic-
`ular vendors. Examples include the
`transport protocols from IBM’s SNA,
`and Digital’s DECnet. However,
`the
`success of the Internet has led nearly all
`vendors in the direction of TCP/IP as
`the future of networking.
`The Internet’s marked success would
`not alone be sufficient justification for
`organizing a survey around a single pro-
`tocol. Also important is that TCP pro-
`vides examples of many significant is-
`sues that arise in transport protocol
`design. The design choices made in TCP
`have been the subject of extensive re-
`view, experimentation, and large-scale
`experience, involving the best research-
`ers and practitioners in the field. TCP
`represents the culmination of many
`
`ACM Computing Surveys, Vol. 31, No. 4, December 1999
`
`years of thought about transport proto-
`col design.
`A final reason that TCP provides a
`good starting point for study, is that the
`history of research and development on
`TCP can be traced in publicly available
`documents. Ongoing research and de-
`velopment of transport protocols, partic-
`ularly TCP, is the focus of two working
`groups of
`the Internet Society. The
`end2end working group of the Internet
`Research Task Force (IRTF, www.irtf.
`org) discusses ongoing long-term re-
`search on transport protocols in general
`(including TCP), while the tcp-impl
`group of the Internet Engineering Task
`Force (IETF, www.ietf.org) focuses on
`short-term TCP implementation issues.
`Both groups maintain active mailing
`lists where ideas are discussed and de-
`bated openly. The work of these groups
`can be found in journal articles, confer-
`ence
`proceedings,
`and
`documents
`known as Internet Drafts and Requests
`for Comments (RFCs). RFCs contain not
`only all the Internet Standards, but also
`other information of historical and tech-
`nical interest. It is much more difficult
`for researchers to obtain similar infor-
`mation concerning proprietary proto-
`cols.
`
`2.2 General Role of the Transport Layer
`
`To illustrate the role that the transport
`layer plays in a familiar application, the
`remainder of Section 2 examines the
`role of TCP in a simple interaction over
`the Web.
`The Web is an example of a client/
`server application. A human interacts
`with a Web browser (client) running on
`a “local” machine. The Web browser
`communicates with a server on some
`“remote” machine. The Web uses an ap-
`plication layer protocol called the Hy-
`pertext Transfer Protocol (HTTP) [Bern-
`ers-Lee et al. 1996]. HTTP is a simple
`request/response protocol. Suppose, for
`example, that you have a personal com-
`puter with Internet access, and you
`wish to retrieve the page “http://www.
`eecis.udel.edu/research.html”
`
`Petitioners' Exhibit 1017
`Page 0003
`
`

`

`from the University of Delaware Web
`site. In the simplest case,1the client
`sends a request containing the filename
`of the desired Web page (“GET /re-
`search.html”)
`to a server
`(“www.
`eecis.udel.edu”),
`and
`the
`server
`sends back a response consisting of the
`contents of that file.
`This communication takes place over
`a complex internetwork of computers
`that is constantly changing in terms of
`both technology and topology. A connec-
`tion between two particular hosts may
`involve such diverse technologies as
`Ethernet, Token Ring, X.25, ATM, PPP,
`SONET, just to name a few. However, a
`programmer writing a Web client or
`server does not want to be concerned
`with the details of how communication
`takes place between client and server.
`The programmer simply wants to send
`and receive messages in a way that does
`not change as the underlying network
`changes. This is the function of the
`transport layer: to provide an abstrac-
`tion of interprocess communication that
`is independent of the underlying net-
`work.
`HTTP uses TCP as the transport
`layer. The programmer writing code for
`an HTTP client or server would access
`TCP’s service through function calls
`that comprise that transport layer’s Ap-
`plication Program Interface (API). At a
`minimum, a transport layer API pro-
`vides functions to send and receive mes-
`sages; for example, the Berkeley Sockets
`API provides functions called write()
`and read() (for more details,
`see
`Stevens [1998]).
`Because TCP is connection-oriented,
`the Berkeley Sockets API also provides
`a connect() function for setting up a
`connection between the local and remote
`processes. It also provides a close()
`
`1To simplify the discussion, we will assume HTTP
`version 0.9 and a document containing only hyper-
`text: no inline images, applets, etc. This avoids
`discussion of HTTP 1.0 headers, persistent con-
`nections as in HTTP 1.1, (which complicate the
`issue of how and when the connection is closed,)
`and the necessity for multiple connections where
`inline images are involved.
`
`Transport Layer
`
`•
`
`363
`
`function for closing a connection. Note
`that while TCP is connection-oriented,
`not all transport services establish a
`connection before data is sent. Connec-
`tion-oriented and connectionless ser-
`vices and protocols are discussed in Sec-
`tions 3.1, 3.2.5 and 4.1.
`
`2.3 Terminology: SDUs, PDUs, and the like
`
`One difficulty in summarizing any topic
`is the wide range of terms used for
`similar concepts. Throughout this pa-
`per, we use a simplified communication
`model (Figure 1) that employs some OSI
`terminology. At the top layer, a user
`sender (e.g., a Web client) has some
`messages to communicate to the user
`receiver (e.g., a Web server). These so-
`called application entities use the ser-
`vice of the transport layer. Communica-
`tion between peer entities consists of an
`exchange
`of Protocol Data Units
`(PDUs). Application peers communicate
`using Application PDUs (APDUs), while
`transport peers
`communicate using
`Transport PDUs (TPDUs), etc. In our
`Web example, the first APDU is the
`request
`“GET /research.html” sent
`from the client (application entity) to
`the server (its peer application entity).
`The Web server will respond with an
`APDU containing the entire text of the
`file “research.html”.
`Many transport and application pro-
`tocols are bidirectional; that is, both
`sides can send and receive data simulta-
`neously. However, it is frequently use-
`ful to focus on one direction while re-
`maining aware that the other direction
`is also operational. As Figure 1 shows,
`each application entity can assume both
`the role of sender and receiver; for the
`APDU “GET /research.html”, the cli-
`ent is the user sender and the server is
`the user receiver (as shown by more
`prominent labels). When the APDU con-
`taining the contents of the file “re-
`search.html” is sent, user sender and
`user receiver reverse roles (as indicated
`by the dotted line boxes, and the lighter
`italicized labels).
`The term transport entity refers to the
`
`ACM Computing Surveys, Vol. 31, No. 4, December 1999
`
`Petitioners' Exhibit 1017
`Page 0004
`
`

`

`364
`
`•
`
`S. Iren et al.
`
`Host A
`
`User Sender
`(Receiver)
`Application (e.g. web client)
`
`Submit
`
`Transport Sender
`(Receiver)
`
`APDUs
`
`TPDUs
`
`Host B
`
`User Receiver
`(Sender)
`Application (e.g. web server)
`
`Deliver
`
`Transport Receiver
`(Sender)
`
`Transmit/Send
`
`Arrive/Receive
`
`Application
`Entities
`
`TSAP
`
`User/Transport
`Interface
`
`Transport
`Entities
`
`NSAP
`
`Transport/Network
`Interface
`
`Network
`
`Figure 1. Transport service.
`
`software within a
`hardware and/or
`given host that implements a particular
`transport service and protocol. Again,
`even when the protocol is bidirectional,
`we focus on one direction for purposes of
`clarity. In this model, the user sender
`submits a chunk of user data (i.e., a
`Transport Service Data Unit (TSDU), or
`informally, a message) to thetransport
`sender. The transport sender transmits
`or sends this data to the transport re-
`ceiver over a network which may provide
`different levels of reliability. The trans-
`port receiver receives the data that ar-
`rives from the network and delivers it to
`the user receiver. Note that even when
`one transport entity assumes the role of
`sender and the other assumes the role
`of receiver, we use solid lines to show
`TPDUs flowing in both directions. This
`illustrates that TPDUs may flow in both
`directions even when user data flows
`only from sender to receiver. TPDUs
`from receiver to sender are examples of
`control TPDUs, which are exchanged
`between transport entities for connec-
`tion management. When the flow of
`user data is bidirectional, control and
`data information can be piggybacked, as
`discussed in Section 4. Control TPDUs
`may flow in both directions between
`sender and receiver, even in the absence
`of user data.
`Figure 2 shows the terminology we
`use to describe what happens to the
`request APDU “GET /research.html”
`as it passes through the various layers
`
`ACM Computing Surveys, Vol. 31, No. 4, December 1999
`
`on its way from the Web client to the
`Web server. When the user sender sub-
`mits the request APDU to the transport
`sender, that APDU becomes a TSDU.
`The transport sender adds its own
`header information to the TSDU, to con-
`struct a TPDU that it can send to the
`transport receiver. TPDUs exchanged
`by the transport entities are encapsu-
`lated (i.e., contained) in NPDUs which
`are exchanged between the network en-
`tities, as illustrated in Figure 2. The
`network layer routes NPDUs between
`the local and remote network entities
`over
`intermediate
`links. When an
`NPDU arrives, the network layer entity
`processes the NPDU header and passes
`the payload of the NPDU to a transport
`layer entity. The transport entity either
`passes the payload of the TPDU to the
`transport user if it is user data, or pro-
`cesses the payload itself if it is a control
`TPDU.
`In the previous paragraph we de-
`scribe a single APDU becoming a single
`TSDU, being encapsulated in a single
`TPDU, which in turn becomes a single
`NSDU encapsulated in a single NPDU.
`This is the simplest case, and one that
`is likely to occur for a small APDU such
`as the HTTP request in our example.
`However, there are many other possibil-
`ities for the relationships between AP-
`DUs, TSDUs, TPDUs, NSDUs, and NP-
`DUs, as described in Step (5) of Section
`2, and also in Sections 3 and 4.
`Figure 2 also shows some of the ter-
`
`Petitioners' Exhibit 1017
`Page 0005
`
`

`

`Application
`(or Session)
`Layer
`
`Transport
`Layer
`
`TPDU
`header
`
`Network
`Layer
`
`NPDU
`header
`
`Transport Layer
`
`•
`
`365
`
`APDU (e.g., "GET /research.html")
`
`TSDU
`
`TPDU (e.g., TCP segment)
`
`NSDU
`
`NPDU (e.g., IP Datagram)
`
`Figure 2. Relationship between Service Data Units (SDUs) and Protocol Data Units (PDUs).
`
`minology commonly used in the Internet
`protocol suite to identify PDUs at vari-
`ous layers. TCP’s PDUs are called seg-
`ments, while IP’s NPDUs are called
`datagrams. However, the Internet com-
`munity’s terminology can be confusing.
`For example, the term packet is often
`used informally to refer to both IP Data-
`grams (NPDUs) and TCP segments (TP-
`DUs). The term datagram can refer ei-
`ther to IP’s NPDUs, or to the TPDUs of
`the User Datagram Protocol. To avoid
`such confusion, we make use of some
`OSI terms throughout the paper. Al-
`though some may criticize OSI termi-
`nology as being cumbersome,
`it often
`has the advantage of being more pre-
`cise.
`
`2.4 Example TCP Connection, Step-by-
`Step
`
`Now let us consider the Web document
`retrieval example, one step at a time.
`This discussion omits many details; the
`purpose here is to provide a general
`understanding of the transport layer in
`the context of a well-known application.
`(1) You select
`“http://www.eecis.
`udel.edu/research.html”
`with
`your Web client.
`the application
`—http indicates
`layer protocol to be used; more
`importantly
`from a
`transport
`layer perspective, it also implic-
`itly indicates the TCP port num-
`
`ber that will be used for the con-
`nection (80,
`in this case). Port
`numbers
`differentiate
`between
`multiple connection points on the
`same machine; for example, be-
`tween servers for Web, File Trans-
`fer Protocol (FTP) and telnet (re-
`mote terminal) requests.
`—“www.eecis.udel.edu” indicates
`the host name to which a TCP
`connection is established. This is
`converted
`to
`the
`IP address
`128.175.2.17 by the Domain
`Name System (which is outside
`the scope of this discussion). The
`combination of IP address and TCP
`port number (128.175.2.17, 80)
`represents what OSI calls a TSAP
`address. A TSAP (Transport Ser-
`vice Access Point) address identi-
`fies one endpoint of a communica-
`tion channel between a process on
`a local machine, and a process on
`a remote machine.
`—“/research.html” is the file you
`are requesting;
`the Web client
`uses this to form the HTTP request
`(APDU)
`“GET /research.html”
`that must be sent to the Web
`server via TCP.
`
`(2) The Web client starts by making a
`connection request to the transport
`entity at (128.175.2.17, 80) by
`calling the connect() function.
`This causes the local-client TCP en-
`
`ACM Computing Surveys, Vol. 31, No. 4, December 1999
`
`Petitioners' Exhibit 1017
`Page 0006
`
`

`

`366
`
`•
`
`S. Iren et al.
`
`tity (or simply, the “local TCP”) to
`initiate a 3-way-handshake with the
`remote-server TCP entity (or sim-
`ply, the “remote TCP”). TPDUs are
`exchanged between the TCP entities
`to ensure reliable connection estab-
`lishment, and to establish initial se-
`quence numbers to be used by the
`transport layer (see Figure 3, and
`Section 4). If the 3-way-handshake
`fails, TCP notifies the application by
`returning an error code as the result
`of the connect() function; other-
`wise a success code is returned. In
`this way, TCP provides what OSI
`calls confirmation of the connect re-
`quest.
`
`(3) Once the connect request is con-
`firmed, the Web client submits a
`request to send data (in this case
`the APDU “GET /research.html”).
`The local TCP then sends this data
`— most likely, in a single TPDU.
`This TPDU (i.e., TCP segment) con-
`tains the service user’s data (the
`TSDU), plus a transport
`layer
`header,
`containing (among other
`things)
`the negotiated initial se-
`quence number for the data. The
`purpose of this sequence number is
`discussed in Step (2).
`
`(4) When the remote TCP receives the
`TPDU,
`the
`data
`“GET
`/re-
`search.html” is buffered. It is de-
`livered when the Web server does a
`read(). In OSI terminology, this
`delivery is known as a data indica-
`tion. The remote TCP also sends
`back an acknowledgment (ACK) con-
`trol TPDU to the local TCP. Ac-
`knowledgments inform the trans-
`port sender about TPDU arrivals
`(see Section 4).
`
`(5) The Web server then responds with
`the contents of “research.html”.
`This file may be too large to be
`efficiently submitted to TCP in one
`write() call, i.e., one TSDU. If so,
`the Web server divides this APDU
`into multiple write() calls,
`i.e.,
`multiple TSDUs. The remote TCP
`
`ACM Computing Surveys, Vol. 31, No. 4, December 1999
`
`then sends these TSDUs to the local
`TCP in multiple TPDUs, utilizing
`the service of the underlying net-
`work layer.
`One interesting aspect of TCP is
`that the sizes of the TSDUs submit-
`ted by the transport entities may
`bear little or no relationship to the
`sizes of
`the TPDUs actually ex-
`changed by TCP. TCP treats the
`flow of data from sender to receiver
`as a byte-stream and segments it in
`whatever manner seems to make
`best use of the underlying network
`service, without regard to TSDU
`boundaries. It delivers data in the
`same fashion; thus for TCP, the
`boundaries between APDUs, sub-
`mitted TSDUs, TPDUs, and deliv-
`ered TSDUs may all be different.
`Other
`transport services/protocols
`have a message orientation, mean-
`ing that they preserve the bound-
`aries of TSDUs (see Section 3).
`
`(6) Because the network layer (IP in
`this case) can lose or reorder NS-
`DUs, TCP must detect and recover
`from network errors. As the remote
`TCP sends the TPDUs containing
`the successive portions of the file
`“research.html”, it includes a se-
`quence number in each TPDU corre-
`sponding to the sequence number of
`the first byte in that TPDU relative
`to the entire flow of data from re-
`mote TCP to local TCP. The remote
`TCP also places a copy of the data in
`each TPDU sent into a buffer, and
`sets a timer. If this timer expires
`before the remote TCP receives a
`matching ACK TPDU from the local
`TCP, the data in the TPDU will be
`retransmitted in a new TPDU. In
`TCP, the data are tracked by indi-
`vidual byte-stream sequence num-
`bers, and TPDUs retransmitted may
`or may not correspond exactly to the
`original TPDUs. The remote TCP
`also places a checksum in the TPDU
`header to detect bit errors intro-
`duced by noise or software errors in
`the network, data link and physical
`
`Petitioners' Exhibit 1017
`Page 0007
`
`

`

`layers. Such error control is a major
`function of the transport layer as
`discussed in Section 4.
`
`(7) As TPDUs are received by the local
`TCP, any TPDUs with checksum er-
`rors are discarded. The sequence
`numbers of the incoming TPDUs are
`checked to ensure that no pieces of
`the byte-stream are missing or have
`arrived out-of-order. Any out-of-or-
`der pieces will be buffered and re-
`ordered. As TPDUs arrive, the local
`TCP responds to the remote TCP
`with ACK TPDUs. If ACKs are lost,
`the remote TCP may send a TPDU
`which duplicates data sent in an
`earlier TPDU. The local TCP also
`discards any duplicate data that ar-
`rives. By detecting and recovering
`from loss, reordering, duplication
`and noise, the local and remote TCP
`entities cooperate to ensure reliable
`delivery of data. As pieces of the
`byte-stream arrive correctly, these
`will be buffered until the Web client
`requests them by doing read()
`calls. Each read() results in deliv-
`ery of a TSDU to the Web client.
`
`(8) In general, a TCP connection is bidi-
`rectional, and either side may ini-
`tiate the closing of the connection.
`However,
`in first-generation Web
`systems,
`the server initiates the
`close by calling the close() func-
`tion after it sends the last piece of
`the file requested. In OSI terminol-
`ogy, this is called a disconnect re-
`quest. TCP handles disconnect re-
`quests with a
`4-way-handshake
`procedure (shown in Figure 4) to
`ensure graceful termination without
`loss of data. The remote TCP re-
`sponds to the server’s disconnect re-
`quest by sending a disconnect TPDU
`and waiting for an ACK TPDU. The
`local TCP signals the server’s dis-
`connect request to the client by re-
`turning “end-of-file” as the result of
`a client read() request. The client
`then responds with its own close()
`request;
`this causes another ex-
`
`Transport Layer
`
`•
`
`367
`
`change of a disconnect TPDU and
`ACK. This procedure and other
`methods of connection termination
`are discussed in Section 4.3.4.
`
`2.5 What this example shows. . . and does
`not show
`
`From this example, we see that TCP
`provides a connection-oriented (CO)
`byte-stream, no-loss, no-duplicates, or-
`dered transport service, and that its
`protocol is designed to operate on top of
`a lossy network service, such as IP
`datagram service [Postel 1981].
`This example also shows a few as-
`pects of communication between the
`user layer and the transport layer, and
`between peer entities. It illustrates one
`example of connection establishment,
`reliable data exchange, and connection
`termination. However, many aspects of
`this example were not discussed, such
`as flow control and congestion avoid-
`ance, piggybacking of ACKs, and round-
`trip-time estimation, to name just a few.
`Also, consider that in the case of a
`Web browser using TCP, the transport
`service is reliable, which means (among
`other things) that the transport service
`may not lose any TSDUs. This guaran-
`tee comes at the expense of potentially
`increased delay, since reliable delivery
`may require more TPDUs to be ex-
`changed. Other transport services (for
`example, those used for audio or video
`transmission) do not provide reliability,
`since for some applications lower delay
`is more important than receiving every
`TSDU.
`Many variations exist both in the type
`of service provided by the transport
`layer, and in the design of transport
`protocols. These variations are what
`make the transport layer so interesting!
`Sections 3 and 4 provide an overview of
`the most important of these variations.
`
`3. TRANSPORT SERVICE
`
`This section classifies the typical service
`provided by the transport layer (see Ta-
`ble I). A transport service abstracts a
`
`ACM Computing Surveys, Vol. 31, No. 4, December 1999
`
`Petitioners' Exhibit 1017
`Page 0008
`
`

`

`368
`
`•
`
`S. Iren et al.
`
`Table I. Transport Service Features
`CO-message vs. CO-byte vs. CL
`No-loss vs. Uncontrolled-loss vs. Controlled-loss
`No-duplicates vs. Maybe-duplicates
`Ordered vs. Unordered vs. Partially-ordered
`Data-integrity vs. No-data-integrity vs. Partial-
`data-integrity
`Blocking vs. Non-blocking
`Multicast vs. Unicast
`Priority vs. No-priority
`Security vs. No-security
`Status-reporting vs. No-status-reporting
`Quality-of-service vs. No-quality-of-service
`
`set of functions that is provided to a
`higher layer. A protocol, on the other
`hand, refers to the details of how a
`transport sender and a transport re-
`ceiver cooperate to provide that service.
`In defining a service, we treat the trans-
`port layer as a black box. In Section 4,
`we look at internal details of that black
`box.
`One of the valuable contributions of
`the OSI Reference Model is its emphasis
`in distinguishing between service and
`protocol. This distinction is not well dif-
`ferentiated in the TCP/IP protocol suite
`where RFCs intermix service and proto-
`col concepts, frequently in a confusing
`manner. As will be seen in Section 4,
`there are often several different protocol
`mechanisms that can provide a given
`service.
`
`3.1 CO-message vs. CO-byte vs. CL
`
`Transport services can be divided into
`two types: connection-oriented and con-
`nectionless. A connection-oriented (CO)
`service provides for the establishment,
`maintenance, and termination of a logi-
`cal connection between transport users.
`The transport user generally performs
`three distinct phases of operation: con-
`nection establishment, data transfer,
`and connection termination. When a
`user sender wants to transmit some
`data to a remote user receiver by using
`a connection-oriented service, the user
`sender first explicitly asks the transport
`sender to open a connection to the re-
`mote transport
`receiver
`(T-Connect).
`
`ACM Computing Surveys, Vol. 31, No. 4, December 1999
`
`Once a connection is established, the
`user
`sender provides
`the transport
`sender with the data to be transmitted
`(T-Data). At the end of the data trans-
`fer, the user sender explicitly asks the
`transport sender to terminate the con-
`nection (T-Disconnect).
`CO service itself has two variations:
`message-oriented and byte-stream.
`In
`the former, the user sender’s messages
`(or what OSI calls service data units
`(SDUs)) have a specified maximum size,
`and message boundaries are preserved.
`When two 1K messages are submitted
`by a user sender, they are delivered to
`the user receiver as the same two dis-
`tinct 1K messages, never for example as
`one 2K message or four .5K messages.
`TP4 is an example that provides mes-
`sage-oriented service.
`In byte-stream
`service as provided by TCP, the flow of
`data from user sender to user receiver is
`viewed as an unstructured sequence of
`bytes that
`flow in a FIFO manner.
`There is no concept of message (or mes-
`sage boundary or maximum message
`size) for the user sender. Data submit-
`ted by a user sender is appended to the
`end of the byte-stream, and the user
`receiver reads from the head of the
`byte-stream.
`An advantage of byte-stream service
`is that it gives the transport sender
`flexibility to divide TSDUs in ways that
`make better use of the underlying net-
`work service. However, byte-stream ser-
`vice has been criticized because it does
`not deliver data to an application in
`meaningful units. A message-oriented
`service better preserves the semantics
`of each APDU down through the lower
`layers for so-called Application Level
`Framing [Clark and Tennenhouse 1990]
`(see Section 6). One research team notes
`that adaptive applications are much
`easier to develop if the unit of process-
`ing (i.e., APDU) is strongly tied to the
`unit of control (i.e., TPDU) [Dabbous
`and Diot 1995].
`A connectionless (CL) service provides
`only one phase of operation: data trans-
`fer. There are no T-Connect and T-Dis-
`
`Petitioners' Exhibit 1017
`Page 0009
`
`

`

`connect primitives exchanged (either ex-
`plicitly or implicitly) between a user
`sender and the transport sender. When
`the user sender has some data, it simply
`submits
`the data to the transport
`sender. As with CO-message service, in
`a CL service the user sender submits
`messages, and message boundaries are
`maintained. Messages submitted to a
`CL service as in UDP often are referred
`to as datagrams.
`
`3.2 Reliability
`
`Unfortunately, the terms reliable and
`unreliable mean different things to dif-
`ferent people. To avoid ambiguity in our
`definition, unless otherwise stated, a
`service is reliable if and only if it is all
`of the following (as defined below): no-
`loss, no-duplicates, ordered, and data-
`integrity. If even one feature is lacking,
`the service is unreliable.
`3.2.1 No-loss vs. Uncontrolled-loss vs.
`Controlled-loss. There are three levels
`of delivery guarantee. A no-loss (or at-
`least-once delivery) service guarantees
`that for all data submitted to the trans-
`port sender by the user sender, one of
`two results will occur. Either (1) the
`data is delivered2 to the user receiver,
`or (2