ust
`
`AA/SWA Ex. 1018, p.1 of 23
`American Airlines, et. al. v. Intellectual Ventures, et.al.
`IPR2025-00786
`
`

`

`UNIX is a technology trademark of X/Open Company, Ltd.
`The publisher offers discounts on this book when ordered in quantity for special sales.
`For more information please contact:
`Corporate & Professional Publishing Group
`Addison-Wesley Publishing Company
`One Jacob Way
`Reading, Massachusetts 01867
`Library of Congress Cataloging-in-Publication Data
`Stevens, W Richard
`TCP/IP Illustrated: the protocols/W Richard Stevens.
`p. em.- (Addison-Wesley professional computing series)
`Includes bibliographical references and index.
`ISBN 0-201-63346-9 (v. 1)
`l.TCP/IP (Computer network protocol) I. Title. II. Series.
`TK5105.55S74 1994
`004.6'2-dc20
`Copyright © 1994 by Addison-Wesley Publishing Company
`All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or
`transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or
`otherwise, without the prior consent of the publisher. Printed in the United States of America.
`Published simultaneously in Canada.
`ISBN 0-201-63346-9
`Text printed on recycled paper.
`2 3 4 5 6 7 8 9 CRW 97969594
`Second Printing, February 1994
`
`AA/SWA Ex. 1018, p.2 of 23
`American Airlines, et. al. v. Intellectual Ventures, et.al.
`IPR2025-00786
`
`

`

`7
`
`Introduction
`
`1.1
`
`Introduction
`The TCP /IP protocol suite allows computers of all sizes, from many different computer
`vendors, running totally different operating systems, to communicate with each other.
`It is quite amazing because its use has far exceeded its original estimates. What started
`in the late 1960s as a government-financed research project into packet switching net-
`works has, in the 1990s, turned into the most widely used form of networking between
`computers. It is truly an open system in that the definition of the protocol suite and
`many of its implementations are publicly available at little or no charge. It forms the
`basis for what is called the worldwide Internet, or the Internet, a wide area network
`(WAN) of more than one million computers that literally spans the globe.
`This chapter provides an overview of the TCP / IP protocol suite, to establish an ade-
`quate background for the remaining chapters. For a historical perspective on the early
`development of TCP liP see [Lynch 1993].
`
`1.2
`
`Layering
`Networking protocols are normally developed in layers, with each layer responsible for a
`different facet of the communications. A protocol suite, such as TCP /IP, is the combina-
`tion of different protocols at various layers. TCP / IP is normally considered to be a
`4-layer system, as shown in Figure 1.1.
`
`1
`
`AA/SWA Ex. 1018, p.3 of 23
`American Airlines, et. al. v. Intellectual Ventures, et.al.
`IPR2025-00786
`
`

`

`2
`
`Introduction
`
`Chapter 1
`
`Application
`Transport
`
`Network
`
`Link
`
`Telnet, FI'P, e-mail, etc.
`TCP,UDP
`IP, ICMP, IGMP
`device driver and interface card
`
`Figure 1.1 The four layers of the TCP / IP protocol swte.
`
`Each layer has a different responsibility.
`1. The link layer, sometimes called the data-link layer or network interface layer, nor-
`mally includes the device driver in the operating system and the corresponding
`network interface card in the computer. Together they handle all the hardware
`details of physically interfacing with the cable (or whatever type of media is
`being used).
`2. The network layer (sometimes called the internet layer) handles the movement of
`packets around the network. Routing of packets, for example, takes place here.
`IP (Internet Protocol), ICMP (Internet Control Message Protocol), and IGMP
`(Internet Group Management Protocol) provide the network layer in the
`TCP /IP protocol suite.
`3. The transport layer provides a flow of data between two hosts, for the applica-
`tion layer above. In the TCP / IP protocol suite there are two vastly different
`transport protocols: TCP (Transmission Control Protocol) and UDP (User Data-
`gram Protocol).
`TCP provides a reliable flow of data between two hosts. It is concerned with
`things such as dividing the data passed to it from the application into appropri-
`ately sized chunks for the network layer below, acknowledging received pack-
`ets, setting timeouts to make certain the other end acknowledges packets that
`are sent, and so on. Because this reliable flow of data is provided by the trans-
`port layer, the application layer can ignore all these details.
`UDP, on the other hand, provides a much simpler service to the application
`layer. It just sends packets of data called datagrams from one host to the other,
`but there is no guarantee that the datagrams reach the other end. Any desired
`reliability must be added by the application layer.
`There is a use for each type of transport protocol, which we'll see when we look
`at the different applications that use TCP and UDP.
`
`AA/SWA Ex. 1018, p.4 of 23
`American Airlines, et. al. v. Intellectual Ventures, et.al.
`IPR2025-00786
`
`

`

`Section 1.2
`
`Layering
`
`3
`
`4. The application layer handles the details of the particular application. There are
`many common TCP / IP applications that almost every implementation pro-
`vides:
`• Telnet for remote login,
`• FfP, the File Transfer Protocol,
`• SMTP, the Simple Mail Transfer protocol, for electronic mail,
`• SNMP, the Simple Network Management Protocol,
`and many more, some of which we cover in later chapters.
`If we have two hosts on a local area network (LAN) such as an Ethernet, both run-
`ning FrP, Figure 1.2 shows the protocols involved.
`
`details + +
`
`handles
`application
`
`user
`processes
`
`kernel
`
`handles
`communication
`details
`
`application
`
`transport
`
`network
`
`link
`
`Ethernet
`
`Figure 1.2 Two hosts on a LAN running FTP.
`We have labeled one application box the FrP client and the other the PIP server.
`Most network applications are designed so that one end is the client and the other side
`the server. The server provides some type of service to clients, in this case access to files
`on the server host. In the remote login application, Telnet, the service provided to the
`client is the ability to login to the server's host.
`Each layer has one or more protocols for communicating with its peer at the same
`layer. One protocol, for example, allows the two TCP layers to communicate, and
`another protocol lets the two IP layers communicate.
`On the right side of Figure 1.2 we have noted that normally the application layer is
`a user process while the lower three layers are usually implemented in the kernel (the
`operating system). Although this isn't a requirement, it's typical and this is the way it's
`done under Unix.
`
`AA/SWA Ex. 1018, p.5 of 23
`American Airlines, et. al. v. Intellectual Ventures, et.al.
`IPR2025-00786
`
`

`

`3
`
`IP: Internet Protocol
`
`3.1
`
`Introduction
`IP is the workhorse protocol of the TCP /IP protocol suite. All TCP, UDP, ICMP, and
`IGMP data gets transmitted as IP datagrams (Figure 1.4). A fact that amazes many
`newcomers to TCP /IP, especially those from an X.25 or SNA background, is that IP pro-
`vides an unreliable, connectionless datagram delivery service.
`By unreliable we mean there are no guarantees that an IP datagram successfully gets
`to its destination. IP provides a best effort service. When something goes wrong, such
`as a router temporarily running out of buffers, IP has a simple error handling algorithm:
`throw away the datagram and try to send an ICMP message back to the source. Any
`required reliability must be provided by the upper layers (e.g., TCP).
`The term connectionless means that IP does not maintain any state information about
`successive datagrams. Each datagram is handled independently from all other data-
`grams. This also means that IP datagrams can get delivered out of order. If a source
`sends two consecutive datagrams (first A, then B) to the same destination, each is
`routed independently and can take different routes, with B arriving before A.
`In this chapter we take a brief look at the fields in the IP header, describe IP routing,
`and cover subnetting. We also look at two useful commands: ifconfig and netstat.
`We leave a detailed discussion of some of the fields in the IP header for later when we
`can see exactly how the fields are used. RFC 791 [Postel 1981a] is the official specifica-
`tion of IP.
`
`33
`
`AA/SWA Ex. 1018, p.6 of 23
`American Airlines, et. al. v. Intellectual Ventures, et.al.
`IPR2025-00786
`
`

`

`34
`
`IP: Internet Protocol
`
`Chapter 3
`
`3.2
`
`IP Header
`Figure 3.1 shows the format of an IP datagram. The normal size of the IP header is 20
`bytes, unless options are present.
`0
`
`31
`
`15 16
`r-bit heade1 8-bit type of service
`length
`(TOS)
`
`4-bit
`version
`
`16-bit identification
`
`16-bit total length (in bytes)
`3-bit I
`flags
`
`13-bit fragment offset
`
`8-bit time to live
`(TTL)
`
`I
`
`8-bit protocol
`
`16-bit header checksum
`
`20 bytes
`
`32-bit source IP address
`
`32-bit destination IP address
`
`options (if any)
`
`data
`
`Figure 3.1 IP datagram, showing the fields in the IP header.
`We will show the pictures of protocol headers in TCP /IP as in Figure 3.1. The most sig-
`nificant bit is numbered 0 at the left, and the least significant bit of a 32-bit value is num-
`bered 31 on the right.
`The 4 bytes in the 32-bit value are transmitted in the order: bits 0- 7 first, then bits
`8-15, then 16-23, and bits 24-31last. This is called big endian byte ordering, which is
`the byte ordering required for all binary integers in the TCP /IP headers as they traverse
`a network. This is called the network byte order. Machines that store binary integers in
`other formats, such as the little endian format, must convert the header values into the
`network byte order before transmitting the data.
`The current protocol version is 4, so IP is sometimes called 1Pv4. Section 3.10 dis-
`cusses some proposals for a new version of IP.
`The header length is the number of 32-bit words in the header, including any options.
`Since this is a 4-bit field, it limits the header to 60 bytes. In Chapter 8 we'll see that this
`limitation makes some of the options, such as the record
`option, useless today.
`The normal value of this field (when no options are present) is 5.
`The type-of-service field (TOS) is composed of a 3-bit precedence field (which is
`ignored today), 4 TOS bits, and an unused bit that must be 0. The 4 TOS bits are: mini-
`mize delay, maximize throughput, maximize reliability, and minimize monetary cost.
`
`AA/SWA Ex. 1018, p.7 of 23
`American Airlines, et. al. v. Intellectual Ventures, et.al.
`IPR2025-00786
`
`

`

`46
`
`IP: Internet Protocol
`
`Chapter3
`
`3. 7 A Subnet Example
`This example shows the subnet used in the text, and how two different subnet masks
`are used. Figure 3.10 shows the arrangement.
`
`Internet
`
`r -- ----- -- --- -------------- -- -------
`SLIP
`subnet
`140.252.13.64
`
`.66
`
`.65
`
`Ethernet, subnet 140.252.1
`
`140.252.1.29
`
`author's subnet: 140.252.13
`Figure 3.10 Arrangement of hosts and networks for author's subnet.
`If you compare this figure with the one on the inside front cover, you'll notice that
`we've omitted the detail that the connection from the router sun to the top Ethernet in
`Figure 3.10 is really a dialup SLIP connection. This detail doesn't affect our description
`of subnetting in this section. We'll return to this detail in Section 4.6 when we describe
`proxy ARP.
`The problem is that we have two separate networks within subnet 13: an Ethernet
`and a point-to-point link (the hardwired SLIP link). (Point-to-point links always cause
`problems since each end normally requires an IP address.) There could be more hosts
`and networks in the future, but not enough hosts across the different networks to justify
`using another subnet number. Our solution is to extend the subnet ID from 8 to 11 bits,
`and decrease the host ID from 8 to 5 bits. This is called variable-length subnets since most
`networks within the 140.252 network use an 8-bit subnet mask while our network uses
`an 11-bit subnet mask.
`RFC 1009 [Braden and Postel 1987] allows a subnetted network to use more than one subnet
`mask. The new Router Requirements RFC [Almquist 1993] requires support for this.
`The problem, however, is that not all routing protocols exchange the subnet mask along with
`the destination network ID. We'll see in Chapter 10 that RIP does not support variable-length
`subnets, while RIP Version 2 and OSPF do. We don't have a problem with our example, since
`RIP isn't required on the author's subnet.
`Figure 3.11 shows the IP address structure used within the author's subnet. The
`first 8 bits of the 11-bit subnet ID are always 13 within the author's subnet. For the
`remaining 3 bits of the subnet ID, we use binary 001 for the Ethernet, and binary 010 for
`
`AA/SWA Ex. 1018, p.8 of 23
`American Airlines, et. al. v. Intellectual Ventures, et.al.
`IPR2025-00786
`
`

`

`Section 3.8
`
`ifconfig Command
`
`47
`
`Class B
`
`16 bits
`net ID = 140.252
`
`Subnet mask:
`
`1 1 1 1 1 1 1 1
`
`1 1 1 1 1 1 1 1
`
`......
`
`----11 bits----
`5 bits
`host!D
`subnetiD
`I
`I
`I
`I
`I
`I
`I
`8 bits- 13
`.... 128 64 32 16 8 4 2 1
`1 1 1 o 0 o o 0 = OxffffffeO
`1 1 1 1 1 1 1 1
`= 255.255.255.224
`
`Figure 3.11 Using variable-length subnets.
`
`the point-to-point SLIP link. This variable-length subnet mask does not cause a prob-
`lem for other hosts and routers in the 140.252 network-as long as all datagrams des-
`tined for the subnet 140.252.13 are sent to the router sun (IP address 140.252.1.29) in
`Figure 3.10, and if sun knows about the 11-bit subnet ID for the hosts on its subnet 13,
`everything is fine.
`The subnet mask for all the interfaces on the 140.252.13 subnet is 255.255.255.224, or
`OxffffffeO. This indicates that the rightmost 5 bits are for the host ID, and the 27 bits
`to the left are the network ID and subnet ID.
`Figure 3.12 shows the allocation of IP addresses and subnet masks for the interfaces
`shown in Figure 3.10.
`Host
`IP address
`140.252.1.29
`sun
`140.252.13.33
`140.252.13.34
`140.252.13.35
`140.252.13.66
`140.252.13.65
`140.252.13.63
`
`svr4
`bsdi
`
`slip
`
`Subnetmask
`255.255.255.0
`255.255.255.224
`255.255.255.224
`255.255.255.224
`255.255.255.224
`255.255.255.224
`255.255.255.224
`
`Net ID/Subnet ID Host ID
`140.252.1
`29
`140.252.13.32
`1
`140.252.13.32
`2
`140.252.13.32
`3
`140.252.13.64
`2
`140.252.13.64
`1
`140.252.13.32
`31
`
`Comment
`on subnet 1
`on author's Ethernet
`
`on Ethernet
`point-to-point
`
`broadcast addr on Ethernet
`
`Figure 3.12 IP addresses on author's subnet.
`The first column is labeled "Host," but both sun and bsdi also act as routers, since
`they are multihomed and route packets from one interface to another.
`The final row in this table notes that the broadcast address for the Ethernet in Fig-
`ure 3.10 is 140.252.13.63: it is formed from the subnet ID of the Ethernet (140.252.13.32)
`and the low-order 5 bits in Figure 3.11 set to 1 (16 + 8 + 4 + 2 + 1 = 31). (We'll see in
`Chapter 12 that this address is called the subnet-directed broadcast address.)
`
`3.8
`
`ifconfig Command
`Now that we've described the link layer and the IP layer we can show the command
`used to configure or query a network interface for use by TCP /IP. The ifconfig(8)
`command is normally run at bootstrap time to configure each interface on a host.
`
`AA/SWA Ex. 1018, p.9 of 23
`American Airlines, et. al. v. Intellectual Ventures, et.al.
`IPR2025-00786
`
`

`

`Section 6.2
`
`ICMP Message Types
`
`71
`
`Query Error
`•
`
`type
`0
`3
`
`4
`5
`
`8
`9
`10
`11
`
`12
`
`13
`14
`15
`16
`17
`18
`
`code
`0
`
`0
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`0
`
`0
`1
`2
`3
`0
`0
`0
`
`0
`1
`
`0
`1
`0
`0
`0
`0
`0
`0
`
`Description
`echo reply (Ping reply, Chapter 7)
`destination unreachable:
`network unreachable (Section 9.3)
`host unreachable (Section 9.3)
`protocol unreachable
`port unreachable (Section 6.5)
`fragmentation needed but don't-fragment bit set (Section 11.6)
`source route failed (Section 8.5)
`destination network unknown
`destination host unknown
`source host isolated (obsolete)
`destination network administratively prohibited
`destination host administratively prohibited
`network unreachable for TOS (Section 9.3)
`host unreachable for TOS (Section 9.3)
`communication administratively prohibited by filtering
`host precedence violation
`precedence cutoff in effect
`source quench (elementary flow control, Section 11.11)
`redirect (Section 9 5):
`redirect for network
`redirect for host
`redirect for type-of-service and network
`redirect for type-of-service and host
`echo request (Ping request, Chapter 7)
`router advertisement (Section 9.6)
`router solicitation (Section 9.6)
`time exceeded:
`time-to-live equals 0 during transit (Traceroute, Chapter 8)
`time-to-live equals 0 during reassembly (Section 11.5)
`parameter problem:
`IP header bad (catchall error)
`required option missing
`timestamp request (Section 6.4)
`timestamp reply (Section 6.4)
`information request (obsolete)
`information reply (obsolete)
`address mask request (Section 6.3)
`address mask reply (Section 6.3)
`
`Figure 6.3 ICMP message types.
`
`•
`•
`•
`
`•
`•
`.
`•
`•
`•
`
`.
`.
`.
`.
`.
`•
`.
`•
`.
`•
`.
`•
`.
`.
`•
`•
`•
`.
`.
`.
`
`•
`
`.
`•
`.
`•
`
`5. A datagram whose source address does not define a single host. This means the
`source address cannot be a zero address, a loopback address, a broadcast
`address, or a multicast address.
`These rules are meant to prevent the broadcast storms that have occurred in the past
`when ICMP errors were sent in response to broadcast packets.
`
`AA/SWA Ex. 1018, p.10 of 23
`American Airlines, et. al. v. Intellectual Ventures, et.al.
`IPR2025-00786
`
`

`

`7
`
`Ping Program
`
`7.1
`
`Introduction
`The name "ping" stands for Packet InterNet Groper. The Ping program tests whether
`another host is reachable. The program sends an ICMP echo request message to a host,
`expecting an ICMP echo reply to be returned. (Figure 6.3 lists all the ICMP message
`types.)
`Normally if you can't Ping a host, you won't be able to Telnet or FfP to that host.
`Conversely, if you can't Telnet to a host, Ping is often the starting point to determine
`what the problem is. Ping also measures the round-trip time to the host, giving us some
`indication of how "far away'' that host is.
`In this chapter we'll use Ping as a diagnostic tool and to further explore ICMP. Ping
`also gives us an opportunity to examine the IP record route and timestamp options.
`Chapter 11 of [Stevens 1990] provides the source code for the Ping program.
`Years ago we could make the unqualified statement that lf we can't Ping a host, we can't Telnet
`or FIP to that host. With the increased awareness of security on the Internet, routers that pro-
`vide access control lists, and firewall gateways, unqualified statements like this are no longer
`true. Reachability of a given host may depend not only on reachability at the TP layer, but also
`on what protocol is being used, and the port numbers involved. Ping may show a host as
`being unreachable, yet we might be able to Telnet to port 25 (the mail server).
`
`7.2
`
`Ping Program
`We call U1e ping program that sends the echo requests the client, and the host being
`pinged the server. Most TCP /IP implementations support the Ping server directly in the
`kernel-the server is not a user process. (The two ICMP query services that we
`described in Chapter 6, the address mask and timestamp requests, are also handled
`directly by the kernel.)
`
`85
`
`AA/SWA Ex. 1018, p.11 of 23
`American Airlines, et. al. v. Intellectual Ventures, et.al.
`IPR2025-00786
`
`

`

`7 7
`
`UDP: User Datagram Protocol
`
`11.1
`
`Introduction
`UDP is a simple, datagram-oriented, transport layer protocol: each output operation by
`a process produces exactly one UDP datagram, which causes one IP datagram to be
`sent. This is different from a stream-oriented protocol such as TCP where the amount of
`data written by an application may have little relationship to what actually gets sent in
`an IP datagram.
`Figure 11.1 shows the encapsulation of a UDP datagram as an IP datagram.
`
`IP datagram
`
`1 ...
`
`UDP datagram
`
`UDPdata
`
`IP
`header
`20 bytes
`
`UDP
`header
`8 bytes
`Figure 11.1 UDP encapsulation.
`RFC 768 [Postel1980] is the official specification of UDP.
`UDP provides no reliability: it sends the datagrams that the application writes to
`the IP layer, but there is no guarantee that they ever reach their destination. Given this
`lack of reliability, we are tempted to think we should avoid UDP and always use a reli-
`able protocol such as TCP. After we describe TCP in Chapter 17 we'll return to this
`topic and see what types of applications can utilize UDP.
`
`143
`
`AA/SWA Ex. 1018, p.12 of 23
`American Airlines, et. al. v. Intellectual Ventures, et.al.
`IPR2025-00786
`
`

`

`144
`
`UDP: User Datagram Protocol
`
`Chapter 11
`
`The application needs to worry about the size of the resulting IP datagram. If it
`exceeds the network's MTU (Section 2.8), the IP datagram is fragmented. This applies
`to each network that the datagram traverses from the source to the destination, not just
`the first network connected to the sending host. (We defined this as the path MTU in
`Section 2.9.) We examine IP fragmentation in Section 11.5.
`
`11.2 UDP Header
`Figure 11.2 shows the fields in the UDP header.
`15 16
`0
`
`16-bit source port number
`
`16-bit UDP length
`
`7
`L
`
`data (if any)
`
`16-bit UDP checksum
`
`16-bit destination port number T
`1
`
`31
`
`8 bytes
`
`Figure 11.2 UDP header.
`The port numbers identify the sending process and the receiving process. In Figure 1.8
`we showed that TCP and UDP use the destination port number to demultiplex incom-
`ing data from IP. Since IP has already demultiplexed the incoming IP datagram to
`either TCP or UDP (based on the protocol value in the IP header), this means the TCP
`port numbers are looked at by TCP, and the UDP port numbers by UDP. The TCP port
`numbers are independent of the UDP port numbers.
`Despite this independence, if a well-known service is provided by both TCP and UDP, the port
`number is normally chosen to be the same for both transport layers. This is purely for conve-
`nience and is not required by the protocols.
`The UDP length field is the length of the UDP header and the UDP data in bytes.
`The minimum value for this field is 8 bytes. (Sending a UDP datagram with 0 bytes of
`data is OK.) This UDP length is redundant. The IP datagram contains its total length in
`bytes (Figure 3.1), so the length of the UDP datagram is this total length minus the
`length of the IP header (which is specified by the header length field in Figure 3.1).
`
`11.3 UDP Checksum
`The UDP checksum covers the UDP header and the UDP data. Recall that the checksum
`in the IP header only covers the IP header-it does not cover any data in the IP
`
`AA/SWA Ex. 1018, p.13 of 23
`American Airlines, et. al. v. Intellectual Ventures, et.al.
`IPR2025-00786
`
`

`

`77
`
`TCP: Transmission Control
`Protocol
`
`17.1
`
`Introduction
`In this chapter we provide a description of the services provided by TCP for the applica-
`tion layer. We also look at the fields in the TCP header. In the chapters that follow we
`examine all of these header fields in more detail, as we see how TCP operates.
`Our description of TCP starts in this chapter and continues in the next seven chap-
`ters. Chapter 18 describes how a TCP connection is established and terminated, and
`Chapters 19 and 20 look at the normal transfer of data, both for interactive use (remote
`login) and bulk data (file transfer). Chapter 21 provides the details of TCP's timeout
`and retransmission, followed by two other TCP timers in Chapters 22 and 23. Finally
`Chapter 24 takes a look at newer TCP features and TCP performance.
`·
`The original specification for TCP is RFC 793 [Postel1981c], although some errors in
`that RFC are corrected in the Host Requirements RFC.
`
`17.2 TCP Services
`Even though TCP and UDP use the same network layer (IP), TCP provides a totally dif-
`ferent service to the application layer than UDP does. TCP provides a connection-
`oriented, reliable, byte stream service.
`The term connection-oriented means the two applications using TCP (normally con-
`sidered a client and a server) must establish a TCP connection with each other before
`they can exchange data. The typical analogy is dialing a telephone number, waiting for
`the other party to answer the phone and say "hello," and then saying who's calling. In
`Chapter 18 we look at how a connection is established, and disconnected some time
`later when either end is done.
`
`223
`
`AA/SWA Ex. 1018, p.14 of 23
`American Airlines, et. al. v. Intellectual Ventures, et.al.
`IPR2025-00786
`
`

`

`224
`
`TCP: Transmission Control Protocol
`
`Chapter 17
`
`There are exactly two end points communicating with each other on a TCP connec-
`tion. Concepts that we talked about in Chapter 12, broadcasting and multicasting,
`aren't applicable to TCP.
`TCP provides reliability by doing the following:
`• The application data is broken into what TCP considers the best sized chunks to
`send. This is totally different from UDP, where each write by the application
`generates a UDP datagram of that size. The unit of information passed by TCP
`to IP is called a segment. (See Figure 1.7, p. 10.) In Section 18.4 we'll see how
`TCP decides what this segment size is.
`• When TCP sends a segment it maintains a timer, waiting for the other end to
`acknowledge reception of the segment. If an acknowledgment isn't received in
`time, the segment is retransmitted. In Chapter 21 we'll look at TCP's adaptive
`timeout and retransmission strategy.
`• When TCP receives data from the other end of the connection, it sends an
`acknowledgment. This acknowledgment is not sent immediately, but normally
`delayed a fraction of a second, as we discuss in Section 19.3.
`• TCP maintains a checksum on its header and data. This is an end-to-end check-
`sum whose purpose is to detect any modification of the data in transit. If a seg-
`ment arrives with an invalid checksum, TCP discards
`it and doesn't
`acknowledge receiving it. (It expects the sender to time out and retransmit.)
`• Since TCP segments are transmitted as IP datagrams, and since IP datagrams
`can arrive out of order, TCP segments can arrive out of order. A receiving TCP
`resequences the data if necessary, passing the received data in the correct order
`to the application.
`• Since IP datagrams can get duplicated, a receiving TCP must discard duplicate
`data.
`• TCP also provides flow control. Each end of a TCP connection has a finite
`amount of buffer space. A receiving TCP only allows the other end to send as
`much data as the receiver has buffers for. This prevents a fast host from taking
`all the buffers on a slower host.
`A stream of 8-bit bytes is exchanged across the TCP connection between the two
`applications. There are no record markers automatically inserted by TCP. This is what
`we called a byte stream service. If the application on one end writes 10 bytes, followed by
`a write of 20 bytes, followed by a write of 50 bytes, the application at the other end of
`the connection cannot tell what size the individual writes were. The other end may
`read the 80 bytes in four reads of 20 bytes at a time. One end puts a stream of bytes into
`TCP and the same, identical stream of bytes appears at the other end.
`Also, TCP does not interpret the contents of the bytes at all. TCP has no idea if the
`data bytes being exchanged are binary data, ASCII characters, EBCDIC characters, or
`whatever. The interpretation of this byte stream is up to the applications on each end of
`the connection.
`
`AA/SWA Ex. 1018, p.15 of 23
`American Airlines, et. al. v. Intellectual Ventures, et.al.
`IPR2025-00786
`
`

`

`Section 17.3
`
`TCP Header
`
`225
`
`This treatment of the byte stream by TCP is similar to the treatment of a file by the Unix oper-
`ating system. The Unix kernel does no interpretation whatsoever of the bytes that an applica-
`tion reads or write-that is up to the applications. There is no distinction to the Unix kernel
`between a binary file or a file containing lines of text.
`
`17.3 TCP Header
`Recall that TCP data is encapsulated in an IP datagram, as shown in Figure 17.1.
`
`IP datagram
`
`TCP segment
`
`.I
`
`TCP data
`
`•I
`I
`
`I•
`I
`
`IP
`header
`20 bytes
`
`TCP
`header
`20 bytes
`Figure 17.1 Encapsulation of TCP data in an IP datagram.
`Figure 17.2 shows the format of the TCP header. Its normal size is 20 bytes, unless
`options are present.
`
`0
`
`15 16
`
`31
`
`16-bit source port number
`
`16-bit destination port number
`
`32-bit sequence number
`
`32-bit acknowledgment number
`
`20 bytes
`
`4-bit header I
`length
`
`reserved
`(6 bits)
`
`16-bit TCP checksum
`
`16-bit window size
`
`16-bit urgent pointer
`
`7
`
`7
`
`options (if any)
`
`data (if any)
`
`Figure 17.2 TCP header.
`
`7
`L
`
`AA/SWA Ex. 1018, p.16 of 23
`American Airlines, et. al. v. Intellectual Ventures, et.al.
`IPR2025-00786
`
`

`

`226
`
`TCP: Transmission Control Protocol
`
`Chapter 17
`
`Each TCP segment contains the source and destination port number to identify the
`sending and receiving application. These two values, along with the source and desti-
`nation IP addresses in the IP header, uniquely identify each connection.
`The combination of an IP address and a port number is sometimes called a socket.
`This term appeared in the original TCP specification (RFC 793), and later it also became
`used as the name of the Berkeley-derived programming interface (Section 1.15). It is the
`socket pair (the 4-tuple consisting of the client IP address, client port number, server IP
`address, and server port number) that specifies the two end points that uniquely identi-
`fies each TCP connection in an internet-
`The sequence number identifies the byte in the stream of data from the sending TCP
`to the receiving TCP that the first byte of data in this segment represents. If we consider
`the stream of bytes flowing in one direction between two applications, TCP numbers
`each byte with a sequence number. This sequence number is a 32-bit unsigned number
`that wraps back around to 0 after reaching 232 - 1.
`When a new connection is being established, the SYN flag is turned on. The
`sequence number field contains the initial sequence number (ISN) chosen by this host for this
`connection. The sequence number of the first byte of data sent by this host will be the
`ISN plus one because the SYN flag consumes a sequence number. (We describe addi-
`tional details on exactly how a connection is established and terminated in the next
`chapter where we'll see that the FIN flag consumes a sequence number also.)
`Since every byte that is exchanged is numbered, the acknowledgment number contains
`the next sequence number that the sender of the acknowledgment expects to receive.
`This is therefore the sequence number plus 1 of the last successfully received byte of
`data. This field is valid only if the ACK flag (described below) is on.
`Sending an ACK costs nothing because the 32-bit acknowledgment number field is
`always part of the header, as is the ACK flag. Therefore we'll see that once a connection
`is established, this field is always set and the ACK flag is always on.
`TCP provides a full-duplex service to the application layer. This means that data can
`be flowing in each direction, independent of the other direction. Therefore, each end of
`a connection must maintain a sequence number of the data flowing in each direction.
`TCP can be described as a sliding-window protocol without selective or negative
`acknowledgments.
`(The sliding window ·protocol used for data transmission is
`described in Section 20.3.) We say that TCP lacks selective acknowledgments because
`the acknowledgment number in the TCP header means that the sender has successfully
`received up through but not including that byte. There is currently no way to acknowl-
`edge selected pieces of the data stream. For example, if bytes 1-1024 are received OK,
`and the next segment contains bytes 2049-3072, the receiver cannot acknowledge this
`new segment. All it can send is an ACK with 1025 as the acknowledgment number.
`There is no means for negatively acknowledging a segment. For example, if the seg-
`ment with bytes 1025-2048 did arrive, but had a checksum error, all the receiving TCP
`can send is an ACK with 1025 as the acknowledgment number. In Section 21.7 we'll see
`how duplicate acknowledgments can help determine that packets have been lost.
`The header length gives the length of the header in 32-bit words. This is required
`because the length of the options field is variable. With a 4-bit field, TCP is limited to a
`60-byte header. Without options, however, the normal size is 20 bytes.