`
`RFC 793 - Transmission Control Protocol
`
`RFC: 793
`
`TRANSMISSION CONTROL PROTOCOL
`
`DARPA INTERNET PROGRAM
`
`PROTOCOL SPECIFICATION
`
`September 1981
`
`prepared for
`
`Defense Advanced Research Projects Agency
`Information Processing Techniques Office
`1400 Wilson Boulevard
`Arlington, Virginia
`22209
`
`by
`
`Information Sciences Institute
`University of Southern California
`4676 Admiralty Way
`Marina del Rey, California
`
`90291
`
`https://datatracker.ietf.org/doc/html/rfic793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018, PAGE 1
`EXHIBIT 1018, PAGE 1
`
`1/175
`
`
`
`7/8/22, 1:07 PM
`
`September 1981
`
`RFC 793 - Transmission Control Protocol
`
`Transmission Control Protocol
`
`TABLE OF CONTENTS
`
`xdO) iii
`
`1.
`
`INTRODUCTION 2... cc ccc ccc ccc ccc cc cece reece rere rere renee ee eeee 1
`
`1.1 MOCAVAtLON .. ccc ccc cc ccc ccc cc eee ee eee eee eee nets eee e scenes 1
`
`1.2 SCOPES Lecce ccc c creer ccc e err eee r cere eee esr eerreeeseereseseseees 2
`1.3 About This Document ....... cc cece cece cece ee eee eee eee eee eeee 2
`1.4 Interfaces ... ccc ccc ccc ccc ccc cee eee ee eee eee eee eee e eee eeeees 3
`1.5 Operation 2... eer c ccc c ccc ccc cee c cree eee e reese eres esse eeeeee 3
`
`2.
`
`PHILOSOPHY 2... ce cc ce ccc cc ee eee ce ee tte e eee eect eee erences 7
`
`2.1 Elements of the Internetwork System ........ ccc ee eee eee ween 7
`2.2 Model OF Operation 2... cece ccc ccc ccc cece ccc ccesseresseseeseeees 7
`2.3 The Host Environment ...... ccc cece cc cece ee ee eee e eee e teres eens 8
`2.4 INterFaceS co.cc csc c cece cece ccc cece reece eee e ects eres sete seeeee 9
`2.5 Relation to Other Protocols 2... ccc ccc cee eee eee weet eee eens 9
`2.6 Reliable Communication .... cece cece ee wee rere ence reeves eeeeees 9
`2.7 Connection Establishment and Clearing ..... cc cece cece cree cceee 10
`2.8 Data COMMUNICATION 2... cece cece cece eee cee eee eeeecees 12
`2.9 Precedence and Security ..... ccc ccc cece cece cece eee teen eee eeee 13
`2.10 Robustness Principle .... ccc ccc ccc cece cece cece cece rere eeeees 13
`
`3.
`
`FUNCTIONAL SPECIFICATION 2.2... ccc cc ccc cc ccc eee ce ee ee cere eee renee 15
`
`3.1 Header Format 2... .. ccc ccc ccc ccc cee ee eee eee reer rene eee eeeees 15
`3.2 Terminology 2... .. ccc ccc ccc ccc ccc cece cece e eee e teen eee eeeees 19
`3.3 Sequence NUMDEFs 2... cee cece cece cece cece cee teers eeeeeeees 24
`3.4 Establishing a CONNECtion 2... cece ccc e cece eee rere reer ee eeees 30
`3.5 Closing a CONNECTION 2... ccc ccc cece cece rere rere rere eee eeeees 37
`3.6 Precedence and Security ...... ccc cece eee e cece cere ee eee eee eceee 40
`3.7 Data Communication ..... ccc cece cece cere eee eee cere e ee eeee 40
`3.8
`Interfaces ... ccc ccc ccc ccc ccc cee ee eee eee ee eee rere eee e eens 44
`3.9 Event ProceSSing .... cece ccc cece eee eee e rere reer eee eeeees 52
`
`GLOSSARY 2... ccc cc cc ccc ec cc ee eee eee ee ee eee eee eee e ee eee tere ee neee 79
`
`REFERENCES 2... ccc ccc ccc cc ec ce cee ere eee eee eee eee eee eee eter ee eeeee 85
`
`https://datatracker.ietf.org/doc/html/rfic793
`
`[Page i]
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018, PAGE 2
`EXHIBIT 1018, PAGE 2
`
`2/175
`
`
`
`7/8/22, 1:07 PM
`
`RFC 793 - Transmission Control Protocol
`
`Transmission Control Protocol
`
`September 1981
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018. PAGE 3
`EXHIBIT 1018, PAGE 3
`
`3/175
`
`
`
`7/8/22, 1:07 PM
`
`[Page ii]
`
`RFC 793 - Transmission Control Protocol
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018. PAGE 4
`EXHIBIT 1018, PAGE 4
`
`4/175
`
`
`
`7/8/22, 1:07 PM
`
`RFC 793 - Transmission Control Protocol
`
`September 1981
`
`Transmission Control Protocol
`
`PREFACE
`
`This document describes the DoD Standard Transmission Control Protocol
`(TCP). There have been nine earlier editions of the ARPA TCP
`specification on which this standard is based, and the present text
`draws heavily from them. There have been many contributors to this work
`both in terms of concepts and in terms of text. This edition clarifies
`several details and removes the end-of-letter buffer-size adjustments,
`and redescribes the letter mechanism as a push function.
`
`Jon Postel
`
`Editor
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018. PAGE 5
`EXHIBIT 1018, PAGE 5
`
`5/175
`
`
`
`7/8/22, 1:07 PM
`
`RFC 793 - Transmission Control Protocol
`
`[Page iii]
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018. PAGE 6
`EXHIBIT 1018, PAGE 6
`
`6/175
`
`
`
`7/8/22, 1:07 PM
`
`RFC 793 - Transmission Control Protocol
`
`RFC:
`793
`Replaces: RFC 761
`IENS:
`129, 124, 112, 81,
`55, 44, 40, 27, 21,
`5
`
`TRANSMISSION CONTROL PROTOCOL
`
`DARPA INTERNET PROGRAM
`PROTOCOL SPECIFICATION
`
`1.
`
`INTRODUCTION
`
`(TCP) is intended for use as a highly
`The Transmission Control Protocol
`reliable host-to-host protocol between hosts in packet-switched computer
`communication networks, and in interconnected systems of such networks.
`
`This document describes the functions to be performed by the
`Transmission Control Protocol,
`the program that implements it, and its
`interface to programs or users that require its services.
`
`1.1. Motivation
`
`Computer communication systems are playing an increasingly important
`role in military, government, and civilian environments. This
`document focuses its attention primarily on military computer
`communication requirements, especially robustness in the presence of
`communication unreliability and availability in the presence of
`congestion, but many of these problems are found in the civilian and
`government sector as well.
`
`As strategic and tactical computer communication networks are
`developed and deployed, it is essential to provide means of
`interconnecting them and to provide standard interprocess
`communication protocols which can support a broad range of
`the
`applications.
`In anticipation of the need for such standards,
`Deputy Undersecretary of Defense for Research and Engineering has
`declared the Transmission Control Protocol
`(TCP) described herein to
`be a basis for DoD-wide inter-process communication protocol
`standardization.
`
`TCP is a connection-oriented, end-to-end reliable protocol designed to
`fit into a layered hierarchy of protocols which support multi-network
`applications.
`The TCP provides for reliable inter-process
`communication between pairs of processes in host computers attached to
`distinct but interconnected computer communication networks. Very few
`assumptions are made as to the reliability of the communication
`protocols below the TCP layer.
`TCP assumes it can obtain a simple,
`potentially unreliable datagram service from the lower level
`protocols.
`In principle,
`the TCP should be able to operate above a
`wide spectrum of communication systems ranging from hard-wired
`connections to packet-switched or circuit-switched networks.
`
`https://datatracker.ietf.org/doc/html/ric793
`
`[Page 1]
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018. PAGE 7
`EXHIBIT 1018, PAGE 7
`
`7/175
`
`
`
`7/8/22, 1:07 PM
`
`RFC 793 - Transmission Control Protocol
`
`Transmission Control Protocol
`Introduction
`
`September 1981
`
`The
`
`TCP is based on concepts first described by Cerf and Kahn in [1].
`TCP fits into a layered protocol architecture just above a basic
`Internet Protocol
`[2] which provides a way for the TCP to send and
`receive variable-length segments of information enclosed in internet
`datagram "envelopes".
`The internet datagram provides a means for
`addressing source and destination TCPs in different networks.
`The
`internet protocol also deals with any fragmentation or reassembly of
`the TCP segments required to achieve transport and delivery through
`multiple networks and interconnecting gateways.
`The internet protocol
`also carries information on the precedence, security classification
`and compartmentation of the TCP segments, so this information can be
`communicated end-to-end across multiple networks.
`
`Protocol Layering
`
`en +
`
`|
`higher-level
`|
`panne nen n een n nnn eeee +
`
`|
`TCP
`|
`een +
`
`|
`internet protocol
`|
`panne nen n een n nen neeee +
`
`| communication network |
`pace nee n ne ene n ne eee eee +
`
`Figure 1
`
`Much of this document is written in the context of TCP implementations
`which are co-resident with higher level protocols in the host
`computer.
`Some computer systems will be connected to networks via
`front-end computers which house the TCP and internet protocol layers,
`as well as network specific software.
`The TCP specification describes
`an interface to the higher level protocols which appears to be
`implementable even for the front-end case, as long as a suitable
`host-to-front end protocol is implemented.
`
`1.2.
`
`Scope
`
`The TCP is intended to provide a reliable process-to-process
`communication service in a multinetwork environment.
`The TCP is
`intended to be a host-to-host protocol in common use in multiple
`networks.
`
`1.3. About this Document
`
`This document represents a specification of the behavior required of
`any TCP implementation, both in its interactions with higher level
`protocols and in its interactions with other TCPs.
`The rest of this
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018. PAGE 8
`EXHIBIT 1018, PAGE 8
`
`8/175
`
`
`
`7/8/22, 1:07 PM
`
`[Page 2]
`
`RFC 793 - Transmission Control Protocol
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018. PAGE 9
`EXHIBIT 1018, PAGE 9
`
`9/175
`
`
`
`7/8/22, 1:07 PM
`
`RFC 793 - Transmission Control Protocol
`
`September 1981
`
`Transmission Control Protocol
`Introduction
`
`section offers a very brief view of the protocol interfaces and
`operation. Section 2 summarizes the philosophical basis for the TCP
`design. Section 3 offers both a detailed description of the actions
`required of TCP when various events occur (arrival of new segments,
`user calls, errors, etc.) and the details of the formats of TCP
`segments.
`
`1.4.
`
`Interfaces
`
`The TCP interfaces on one side to user or application processes and on
`the other side to a lower level protocol such as Internet Protocol.
`
`The interface between an application process and the TCP is
`illustrated in reasonable detail. This interface consists of a set of
`calls much like the calls an operating system provides to an
`application process for manipulating files.
`For example,
`there are
`calls to open and close connections and to send and receive data on
`established connections.
`It is also expected that the TCP can
`asynchronously communicate with application programs. Although
`considerable freedom is permitted to TCP implementors to design
`interfaces which are appropriate to a particular operating system
`environment, a minimum functionality is required at the TCP/user
`interface for any valid implementation.
`
`The interface between TCP and lower level protocol is essentially
`unspecified except that it is assumed there is a mechanism whereby the
`two levels can asynchronously pass information to each other.
`Typically, one expects the lower level protocol to specify this
`interface.
`TCP is designed to work in a very general environment of
`interconnected networks.
`The lower level protocol which is assumed
`throughout this document is the Internet Protocol [2].
`
`1.5. Operation
`
`the primary purpose of the TCP is to provide reliable,
`As noted above,
`securable logical circuit or connection service between pairs of
`processes.
`To provide this service on top of a less reliable internet
`communication system requires facilities in the following areas:
`
`Basic Data Transfer
`Reliability
`Flow Control
`Multiplexing
`Connections
`Precedence and Security
`
`The basic operation of the TCP in each of these areas is described in
`the following paragraphs.
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018. PAGE 10
`EXHIBIT 1018, PAGE 10
`
`10/175
`
`
`
`7/8/22, 1:07 PM
`
`RFC 793 - Transmission Control Protocol
`
`[Page 3]
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018, PAGE 11
`EXHIBIT 1018, PAGE 11
`
`11/175
`
`
`
`7/8/22, 1:07 PM
`
`RFC 793 - Transmission Control Protocol
`
`September 1981
`
`Transmission Control Protocol
`Introduction
`
`Basic Data Transfer:
`
`The TCP is able to transfer a continuous stream of octets in each
`direction between its users by packaging some number of octets into
`segments for transmission through the internet system.
`In general,
`the TCPs decide when to block and forward data at their own
`convenience.
`
`Sometimes users need to be sure that all the data they have
`submitted to the TCP has been transmitted.
`For this purpose a push
`function is defined.
`To assure that data submitted to a TCP is
`actually transmitted the sending user indicates that it should be
`pushed through to the receiving user.
`A push causes the TCPs to
`promptly forward and deliver data up to that point to the receiver.
`The exact push point might not be visible to the receiving user and
`the push function does not supply a record boundary marker.
`
`Reliability:
`
`lost, duplicated, or
`The TCP must recover from data that is damaged,
`delivered out of order by the internet communication system. This
`is achieved by assigning a sequence number to each octet
`transmitted, and requiring a positive acknowledgment
`(ACK)
`receiving TCP.
`If the ACK is not received within a timeout
`interval,
`the data is retransmitted. At the receiver,
`the sequence
`numbers are used to correctly order segments that may be received
`out of order and to eliminate duplicates. Damage is handled by
`adding a checksum to each segment transmitted, checking it at the
`receiver, and discarding damaged segments.
`
`from the
`
`As long as the TCPs continue to function properly and the internet
`system does not become completely partitioned, no transmission
`errors will affect the correct delivery of data.
`TCP recovers from
`internet communication system errors.
`
`Flow Control:
`
`TCP provides a means for the receiver to govern the amount of data
`sent by the sender. This is achieved by returning a "window" with
`every ACK indicating a range of acceptable sequence numbers beyond
`the last segment successfully received.
`The window indicates an
`allowed number of octets that the sender may transmit before
`receiving further permission.
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018, PAGE 12
`EXHIBIT 1018, PAGE 12
`
`12/175
`
`
`
`7/8/22, 1:07 PM
`
`[Page 4]
`
`RFC 793 - Transmission Control Protocol
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018. PAGE 13
`EXHIBIT 1018, PAGE 13
`
`13/175
`
`
`
`7/8/22, 1:07 PM
`
`RFC 793 - Transmission Control Protocol
`
`September 1981
`
`Multiplexing:
`
`Transmission Control Protocol
`Introduction
`
`To allow for many processes within a single Host to use TCP
`communication facilities simultaneously,
`the TCP provides a set of
`addresses or ports within each host. Concatenated with the network
`and host addresses from the internet communication layer, this forms
`a socket.
`A pair of sockets uniquely identifies each connection.
`That is, a socket may be simultaneously used in multiple
`connections.
`
`The binding of ports to processes is handled independently by each
`Host. However, it proves useful to attach frequently used processes
`(e.g., a "logger" or timesharing service) to fixed sockets which are
`made known to the public. These services can then be accessed
`through the known addresses. Establishing and learning the port
`addresses of other processes may involve more dynamic mechanisms.
`
`Connections:
`
`The reliability and flow control mechanisms described above require
`that TCPs initialize and maintain certain status information for
`each data stream.
`The combination of this information,
`including
`sockets, sequence numbers, and window sizes,
`is called a connection.
`Each connection is uniquely specified by a pair of sockets
`identifying its two sides.
`
`When two processes wish to communicate, their TCP's must first
`establish a connection (initialize the status information on each
`Side). When their communication is complete,
`the connection is
`terminated or closed to free the resources for other uses.
`
`Since connections must be established between unreliable hosts and
`over the unreliable internet communication system, a handshake
`mechanism with clock-based sequence numbers is used to avoid
`erroneous initialization of connections.
`
`Precedence and Security:
`
`The users of TCP may indicate the security and precedence of their
`communication. Provision is made for default values to be used when
`these features are not needed.
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018, PAGE 14
`EXHIBIT 1018, PAGE 14
`
`14/175
`
`
`
`7/8/22, 1:07 PM
`
`RFC 793 - Transmission Control Protocol
`
`[Page 5]
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018. PAGE 15
`EXHIBIT 1018, PAGE 15
`
`15/175
`
`
`
`7/8/22, 1:07 PM
`
`RFC 793 - Transmission Control Protocol
`
`Transmission Control Protocol
`
`September 1981
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018. PAGE 16
`EXHIBIT 1018, PAGE 16
`
`16/175
`
`
`
`7/8/22, 1:07 PM
`
`[Page 6]
`
`RFC 793 - Transmission Control Protocol
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018, PAGE 17
`EXHIBIT 1018, PAGE 17
`
`17/175
`
`
`
`7/8/22, 1:07 PM
`
`RFC 793 - Transmission Control Protocol
`
`September 1981
`
`Transmission Control Protocol
`
`2.1. Elements of the Internetwork System
`
`2.
`
`PHILOSOPHY
`
`The internetwork environment consists of hosts connected to networks
`which are in turn interconnected via gateways.
`It is assumed here
`that the networks may be either local networks (e.g.,
`the ETHERNET) or
`large networks (e.g.,
`the ARPANET), but in any case are based on
`packet switching technology.
`The active agents that produce and
`consume messages are processes. Various levels of protocols in the
`networks,
`the gateways, and the hosts support an interprocess
`communication system that provides two-way data flow on logical
`connections between process ports.
`
`The term packet is used generically here to mean the data of one
`transaction between a host and its network.
`The format of data blocks
`exchanged within the a network will generally not be of concern to us.
`
`Hosts are computers attached to a network, and from the communication
`network's point of view, are the sources and destinations of packets.
`Processes are viewed as the active elements in host computers (in
`accordance with the fairly common definition of a process as a program
`in execution).
`Even terminals and files or other I/0 devices are
`viewed as communicating with each other through the use of processes.
`Thus, all communication is viewed as inter-process communication.
`
`Since a process may need to distinguish among several communication
`streams between itself and another process (or processes), we imagine
`that each process may have a number of ports through which it
`communicates with the ports of other processes.
`
`2.2. Model of Operation
`
`Processes transmit data by calling on the TCP and passing buffers of
`data as arguments.
`The TCP packages the data from these buffers into
`segments and calls on the internet module to transmit each segment to
`the destination TCP.
`The receiving TCP places the data from a segment
`into the receiving user's buffer and notifies the receiving user.
`The
`TCPs include control information in the segments which they use to
`ensure reliable ordered data transmission.
`
`The model of internet communication is that there is an internet
`protocol module associated with each TCP which provides an interface
`to the local network. This internet module packages TCP segments
`inside internet datagrams and routes these datagrams to a destination
`internet module or intermediate gateway.
`To transmit the datagram
`through the local network, it is embedded in a local network packet.
`
`The packet switches may perform further packaging, fragmentation, or
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018. PAGE 18
`EXHIBIT 1018, PAGE 18
`
`18/175
`
`
`
`7/8/22, 1:07 PM
`
`RFC 793 - Transmission Control Protocol
`
`[Page 7]
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018. PAGE 19
`EXHIBIT 1018, PAGE 19
`
`19/175
`
`
`
`7/8/22, 1:07 PM
`
`RFC 793 - Transmission Control Protocol
`
`Transmission Control Protocol
`Philosophy
`
`September 1981
`
`other operations to achieve the delivery of the local packet to the
`destination internet module.
`
`the internet datagram is "unwrapped"
`At a gateway between networks,
`from its local packet and examined to determine through which network
`the internet datagram should travel next.
`The internet datagram is
`then "wrapped" in a local packet suitable to the next network and
`routed to the next gateway, or to the final destination.
`
`A gateway is permitted to break up an internet datagram into smaller
`internet datagram fragments if this is necessary for transmission
`through the next network.
`To do this,
`the gateway produces a set of
`internet datagrams; each carrying a fragment.
`Fragments may be
`The
`further broken into smaller fragments at subsequent gateways.
`internet datagram fragment format is designed so that the destination
`internet module can reassemble fragments into internet datagrams.
`
`A destination internet module unwraps the segment from the datagram
`(after reassembling the datagram, if necessary) and passes it to the
`destination TCP.
`
`This simple model of the operation glosses over many details. One
`important feature is the type of service. This provides information
`to the gateway (or internet module) to guide it in selecting the
`service parameters to be used in traversing the next network.
`Included in the type of service information is the precedence of the
`datagram. Datagrams may also carry security information to permit
`host and gateways that operate in multilevel secure environments to
`properly segregate datagrams for security considerations.
`
`2.3.
`
`The Host Environment
`
`The users
`The TCP is assumed to be a module in an operating system.
`The TCP
`access the TCP much like they would access the file system.
`to manage
`may call on other operating system functions, for example,
`data structures.
`The actual interface to the network is assumed to be
`controlled by a device driver module.
`The TCP does not call on the
`network device driver directly, but rather calls on the internet
`datagram protocol module which may in turn call on the device driver.
`
`The mechanisms of TCP do not preclude implementation of the TCP in a
`front-end processor. However,
`in such an implementation, a
`host-to-front-end protocol must provide the functionality to support
`the type of TCP-user interface described in this document.
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018. PAGE 20
`EXHIBIT 1018, PAGE 20
`
`20/175
`
`
`
`7/8/22, 1:07 PM
`
`[Page 8]
`
`RFC 793 - Transmission Control Protocol
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018, PAGE 21
`EXHIBIT 1018, PAGE 21
`
`21/175
`
`
`
`7/8/22, 1:07 PM
`
`RFC 793 - Transmission Control Protocol
`
`September 1981
`
`2.4.
`
`Interfaces
`
`Transmission Control Protocol
`Philosophy
`
`The TCP/user interface provides for calls made by the user on the TCP
`to OPEN or CLOSE a connection,
`to SEND or RECEIVE data, or to obtain
`STATUS about a connection. These calls are like other calls from user
`programs on the operating system, for example,
`the calls to open,
`read
`from, and close a file.
`
`The TCP/internet interface provides calls to send and receive
`datagrams addressed to TCP modules in hosts anywhere in the internet
`system. These calls have parameters for passing the address,
`type of
`service, precedence, security, and other control information.
`
`2.5. Relation to Other Protocols
`
`The following diagram illustrates the place of the TCP in the protocol
`hierarchy:
`
`te----- + t----- + t----- +
`
`teonee +
`
`|Voice|
`| FTP |
`|Telnet|
`$------ + t----- + +----- +
`
`...
`
`| Application Level
`|
`$o---- +
`
`|
`|
`oceee +
`
`| TcP |
`$----- +
`
`|
`$ace-- +
`
`|
`$oneee +
`
`| Host Level
`| RTP |... |
`$----- +
`$o---- +
`
`|
`|
`|
`en +
`
`| Gateway Level
`Internet Protocol & ICMP
`|
`face nnn ene nee n nena n en eeee- +
`
`|
`ees +
`
`|
`Local Network Protocol
`|
`pace nee nee een n enn e nen eee +
`
`Network Level
`
`Protocol Relationships
`
`Figure 2.
`
`It is expected that the TCP will be able to support higher level
`protocols efficiently.
`It should be easy to interface higher level
`protocols like the ARPANET Telnet or AUTODIN II THP to the TCP.
`
`2.6. Reliable Communication
`
`A stream of data sent on a TCP connection is delivered reliably and in
`order at the destination.
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018, PAGE 22
`EXHIBIT 1018, PAGE 22
`
`22/175
`
`
`
`7/8/22, 1:07 PM
`
`RFC 793 - Transmission Control Protocol
`
`[Page 9]
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018. PAGE 23
`EXHIBIT 1018, PAGE 23
`
`23/175
`
`
`
`7/8/22, 1:07 PM
`
`RFC 793 - Transmission Control Protocol
`
`Transmission Control Protocol
`Philosophy
`
`September 1981
`
`Transmission is made reliable via the use of sequence numbers and
`acknowledgments. Conceptually, each octet of data is assigned a
`sequence number.
`The sequence number of the first octet of data ina
`segment is transmitted with that segment and is called the segment
`sequence number.
`Segments also carry an acknowledgment number which
`is the sequence number of the next expected data octet of
`transmissions in the reverse direction. When the TCP transmits a
`segment containing data, it puts a copy on a retransmission queue and
`starts a timer; when the acknowledgment for that data is received,
`the
`segment is deleted from the queue.
`If the acknowledgment is not
`received before the timer runs out,
`the segment is retransmitted.
`
`An acknowledgment by TCP does not guarantee that the data has been
`delivered to the end user, but only that the receiving TCP has taken
`the responsibility to do so.
`
`To govern the flow of data between TCPs, a flow control mechanism is
`employed.
`The receiving TCP reports a "window" to the sending TCP.
`This window specifies the number of octets, starting with the
`acknowledgment number, that the receiving TCP is currently prepared to
`receive.
`
`2.7. Connection Establishment and Clearing
`
`the TCP
`To identify the separate data streams that a TCP may handle,
`provides a port identifier. Since port identifiers are selected
`independently by each TCP they might not be unique.
`To provide for
`unique addresses within each TCP, we concatenate an internet address
`identifying the TCP with a port identifier to create a socket which
`will be unique throughout all networks connected together.
`
`A connection is fully specified by the pair of sockets at the ends.
`local socket may participate in many connections to different foreign
`sockets.
`A connection can be used to carry data in both directions,
`that is, it is "full duplex".
`
`A
`
`TCPs are free to associate ports with processes however they choose.
`However, several basic concepts are necessary in any implementation.
`There must be well-known sockets which the TCP associates only with
`the "appropriate" processes by some means. We envision that processes
`may "own" ports, and that processes can initiate connections only on
`the ports they own.
`(Means for implementing ownership is a local
`issue, but we envision a Request Port user command, or a method of
`uniquely allocating a group of ports to a given process, e.g., by
`associating the high order bits of a port name with a given process.)
`
`A connection is specified in the OPEN call by the local port and
`foreign socket arguments.
`In return,
`the TCP supplies a (short) local
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018, PAGE 24
`EXHIBIT 1018, PAGE 24
`
`24/175
`
`
`
`7/8/22, 1:07 PM
`
`[Page 10]
`
`RFC 793 - Transmission Control Protocol
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018. PAGE 25
`EXHIBIT 1018, PAGE 25
`
`25/175
`
`
`
`7/8/22, 1:07 PM
`
`RFC 793 - Transmission Control Protocol
`
`September 1981
`
`Transmission Control Protocol
`Philosophy
`
`connection name by which the user refers to the connection in
`subsequent calls. There are several things that must be remembered
`about a connection.
`To store this information we imagine that there
`is a data structure called a Transmission Control Block (TCB). One
`implementation strategy would have the local connection name be a
`pointer to the TCB for this connection.
`The OPEN call also specifies
`whether the connection establishment is to be actively pursued, or to
`be passively waited for.
`
`A passive OPEN request means that the process wants to accept incoming
`connection requests rather than attempting to initiate a connection.
`Often the process requesting a passive OPEN will accept a connection
`request from any caller.
`In this case a foreign socket of all zeros
`is used to denote an unspecified socket. Unspecified foreign sockets
`are allowed only on passive OPENs.
`
`A service process that wished to provide services for unknown other
`processes would issue a passive OPEN request with an unspecified
`foreign socket.
`Then a connection could be made with any process that
`requested a connection to this local socket.
`It would help if this
`local socket were known to be associated with this service.
`
`Well-known sockets are a convenient mechanism for a priori associating
`a socket address with a standard service.
`For instance,
`the
`"Telnet-Server" process is permanently assigned to a particular
`socket, and other sockets are reserved for File Transfer, Remote Job
`Entry, Text Generator, Echoer, and Sink processes (the last three
`being for test purposes).
`A socket address might be reserved for
`access to a "Look-Up" service which would return the specific socket
`at which a newly created service would be provided.
`The concept of a
`well-known socket is part of the TCP specification, but the assignment
`of sockets to services is outside this specification.
`(See [4].)
`
`Processes can issue passive OPENs and wait for matching active OPENs
`from other processes and be informed by the TCP when connections have
`been established.
`Two processes which issue active OPENs to each
`other at the same time will be correctly connected. This flexibility
`is critical for the support of distributed computing in which
`components act asynchronously with respect to each other.
`
`There are two principal cases for matching the sockets in the local
`passive OPENs and an foreign active OPENs.
`In the first case,
`the
`local passive OPENs has fully specified the foreign socket.
`In this
`case,
`the match must be exact.
`In the second case,
`the local passive
`OPENs has left the foreign socket unspecified.
`In this case, any
`foreign socket is acceptable as long as the local sockets match.
`Other possibilities include partially restricted matches.
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018. PAGE 26
`EXHIBIT 1018, PAGE 26
`
`26/175
`
`
`
`7/8/22, 1:07 PM
`
`RFC 793 - Transmission Control Protocol
`
`[Page 11]
`
`https://datatracker.ietf.org/doc/html/ric793
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1018, PAGE 27
`EXHIBIT 1018, PAGE 27
`
`27/175
`
`
`
`7/8/22, 1:07 PM
`
`RFC 793 - Transmission Control Protocol
`
`Transmission Control Protocol
`Philosophy
`
`September 1981
`
`If there are several pending passive OPENs (recorded in TCBs) with the
`same local socket, an foreign active OPEN will be matched to a TCB
`with the specific foreign socket in the foreign active OPEN, if such a
`TCB exists, before selecting a TCB with an unspecified foreign socket.
`
`The procedures to establish connections utilize the synchronize (SYN)
`control flag and involves an exchange of three messages. This
`exchange has been termed a three-way hand shake [3].
`
`A connection is initiated by the rendezvous of an arriving segment
`containing a SYN and a waiting TCB entry each created by a user OPEN
`command.
`The matching of local and foreign sockets determines when a
`connection has been initiated.
`The connection becomes "established"
`when sequence numbers have been synchronized in both directions.
`
`The clearing of a connection also involves the exchange of segments,
`in this case carrying the FIN control flag.
`
`2.8. Data Communication
`
`The data that flows on a connection may be thought of as a stream of
`octets.
`The sending user indicates in each SEND call whether the data
`in that call (and any preceeding calls) should be immediately pushed
`through to the receiving user by the setting of the PUSH flag.
`
`A sending TCP is allowed to collect data from the sending user and to
`send that data in segments at its own convenience, until the push
`function is signaled,
`then it must send all unsent data. When a
`receiving TCP sees the PUSH flag, it must not wait for more data from
`the sending TCP before passing the data to the receiving process.
`
`There is no necessary relationship between push function