Chapter 7 Reliable Delivery with TCP

1
Chapter 7 Reliable Delivery with TCP
Many applications can not tolerate UDPs
limitations. They need assurance that their data
actually makes it to the destination. In
addition, their messages must often arrive in a
particular order. There applications need
reliable data delivery, and the Transmission
Control Protocol provides it for them.
This chapter examines reliable delivery and and
TCP in three stages 1. Introduce the concepts
behind reliable delivery 2. Explain the TCP
specification and document how a system must
behave when using TCP 3. Present several
important guidelines for TCP implementation
2
Chapter 7 Reliable Delivery with TCP
The Principle behind Reliable Delivery
The meaning of reliability
3
Chapter 7 Reliable Delivery with TCP
The Principle behind Reliable Delivery
The meaning of reliability
TCP, by itself, cannot provide absolute
reliability. When data reaches its destination,
TCP can reliably deliver that data to an
application protocol. TCP cannot, however,
guarantee that the application protocol
successfully processes the data.
For example, in FTP, TCP can deliver data to the
file transfer application. If the disk crashes,
however, and the application is unable to write
the data, then there is nothing that TCP can do.
If an application needs absolute reliability,
then it must provide that itself.
4
Chapter 7 Reliable Delivery with TCP
The Principle behind Reliable Delivery
TCP eliminates errors
The most basic quality of reliable delivery is
that it be free from errors. Data that TCP
delivers to the recipient should be exactly the
same data that the sender gave TCP originally.
In a rigorous sense, this quality is impossible
to attain. TCP, compromises, therefore, by
providing a nearly error-free service. TCP cannot
absolutely prevent all undetected errors, but it
can make them extremely rare.
5
Chapter 7 Reliable Delivery with TCP
The Principle behind Reliable Delivery
TCP assures delivery
When TCP accepts a message from an application,
it also accepts responsibility for delivering
that message. TCP guarantees that data reaches
its destination.
Of course, successful delivery is not always
possible. The recipient, for example, may lose
power (crash) before the data arrives. When TCP
cannot delivery data, it will tell the sending
application of the failure.
6
Chapter 7 Reliable Delivery with TCP
The Principle behind Reliable Delivery
TCP assures delivery
Crash recovery
When sender crashes, after recovery, it can ask
receivers for status.
When the receiver crashes, assume the sender is
in one of the two states One TPDU (TCP Protocol
Data Unit) outstanding, S1, or no TPDUs
outstanding, S0.
7
Chapter 7 Reliable Delivery with TCP
The Principle behind Reliable Delivery
TCP assures delivery
Crash recovery
strategy used by receiving host
first ack, then write first write, then ack
strategy used by sending host ac(w)
awc c(aw) c(wa) wac wc(a) always retransmit
OK DUP OK OK DUP DUP never
retransmit Lost OK Lost Lost OK
OK retransmit in S0 OK DUP Lost
Lost DUP OK retransmit in S1 Lost OK
OK OK OK DUP
OK protocol functions correctly DUP protocol
generates a duplicate message Lost protocol
loses a message
8
Chapter 7 Reliable Delivery with TCP
The Principle behind Reliable Delivery
TCP provides in-sequence delivery
TCP also endeavors to deliver data in sequence.
This service ensures that the recipient receives
the data in the same order that the sender sends
it.
Sometimes, it is easy to overlook the importance
of in-sequence delivery. Does order really matter
as long as the data actually arrives? The answer
is definitely yes.
9
Chapter 7 Reliable Delivery with TCP
The Principle behind Reliable Delivery
TCP provides in-sequence delivery
10
Chapter 7 Reliable Delivery with TCP
The Principle behind Reliable Delivery
TCP eliminates duplication
TCP makes sure that data messages are only
delivery once. Sometimes receiving many copies of
a message is just as bad as (or even worse than)
not receiving the message at all.
Again, the clearest example arises when the
message contains commands as well as data.
Imagine the consequences if a single request for
a wire funds transfer arrives at a bank several
times.
11
Chapter 7 Reliable Delivery with TCP
The Principle behind Reliable Delivery
TCP operates end-to-end
No TCP in intermediate routers
12
Chapter 7 Reliable Delivery with TCP
The Principle behind Reliable Delivery
TCP operates end-to-end
application
application
7
application
application
presentation
6
presentation
session
5
session
transport
transport
4
network
3
network
communication network
data link
data link
2
physical
1
physical
13
Chapter 7 Reliable Delivery with TCP
The Need for Transport Protocols
The characteristics of TCPs reliable delivery
are often characteristics of subnetwork
technologies. Given this fact, why are transport
protocols even needed? If a packet travels across
several subnetworks, each of which is reliable by
itself, how could the overall path not be
reliable?
Even though the subnetworks themselves all
provide error-free delivery, it may still be the
case that a packet traveling through them does
not arrive error-free. Of course, like TCP
itself, subnetwork error-detection methods are
not perfect they cannot detect every possible
error. Most of them, however, are far better than
TCPs approach.
14
Chapter 7 Reliable Delivery with TCP
The Need for Transport Protocols
Example a likely source of errors is not the
subnetworks, but the routers that connect
subnetworks.
15
Chapter 7 Reliable Delivery with TCP
The Need for Transport Protocols
Detecting these types of errors requires work at
the endpoints of the connection. Transport
protocols can detect such errors because they
rely on error-detection codes inserted by the
original sender. These codes are not recomputed
by hardware interfaces along the way, and they
will thus detect errors that the subnetworks can
miss.
Therefore, a collection of reliable subnetworks
does not ensure that the entire path remains
reliable. Transport level protocols like TCP
provide that reliability.
16
Chapter 7 Reliable Delivery with TCP
The Need for Transport Protocols
Similarities and differences to subnetwork
protocols
datalink layer protocol
host
host
subnet
physical communication channel
Both have to deal with error control, sequencing,
and flow control, among others.
17
Chapter 7 Reliable Delivery with TCP
The Need for Transport Protocols
Similarities and differences to subnetwork
protocols
datalink layer protocol
host
host
subnet
Differences 1. explicit addressing of
destinations 2. connection establishment is more
complicated 3. potential existence of storage
capacity in the subnet 4. a large and dynamically
varying number of connections
18
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
For TCP, the basis for reliable delivery is
connection. Like transport protocols from other
protocol suites, TCP relies on connection-oriented
operation.
Connections establish a context for
communications. This context allows TCP to relate
different packets with each other, and with such
a relationship, TCP can identify the sequence of
individual packets, recognize duplicate packets,
and determine when particular packets are missing.
19
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Identifying Connections
Most TCP implementations can simultaneously
support many connections to many different
systems.
20
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Identifying Connections
multiplexing
21
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Identifying Connections
TCP relies on socket pairs to identify individual
connections. TCP uses sockets to identify
endpoints of a connection, and, since every
connection has two endpoints, a pair of sockets
can uniquely identify a connection.
Many applications that use TCP depend on
well-known ports. Well-known ports are predefined
port values that, by prior agreement, belong to
particular application protocols.
22
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Identifying Connections
23
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Identifying Connections
TCP ports in www.csie.ndhu.edu.tw
tcpmux 1/tcp echo 7/tcp discard 9/tcp sink
null systat 11/tcp users daytime 13/tcp netstat
15/tcp chargen 19/tcp ttytst source ftp-data 20/
tcp ftp 21/tcp telnet 23/tcp
24
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Identifying Connections
TCP ports in www.csie.ndhu.edu.tw
smtp 25/tcp mail time 37/tcp timserver whois
43/tcp nicname usually to sri-nic domain 53/tc
p hostnames 101/tcp hostname usually to
sri-nic sunrpc 111/tcp rpcbind rje 77/tcp finge
r 79/tcp link 87/tcp ttylink supdup 95/tcp iso
-tsap 102/tcp
25
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Identifying Connections
TCP ports in www.csie.ndhu.edu.tw
x400 103/tcp ISO Mail x400-snd 104/tcp csnet
-ns 105/tcp pop-2 109/tcp Post
Office uucp-path 117/tcp nntp 119/tcp
usenet Network News Transfer ntp 123/t
cp Network Time Protocol NeWS 144/tcp news
Window System exec 512/tcp login 513/tcp shel
l 514/tcp cmd no passwords used
26
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Identifying Connections
TCP ports in www.csie.ndhu.edu.tw
printer 515/tcp spooler line printer
spooler courier 530/tcp rpc
experimental uucp 540/tcp uucpd uucp
daemon pcserver 600/tcp ECD Integrated PC
board srvr kerberos 750/tcp kdc Kerberos key
server ufsd 1008/tcp ufsd UFS-aware
server ingreslock 1524/tcp listen
2766/tcp System V
listener port nfsd 2049/tcp nfs NFS server
daemon (cots) lockd 4045/tcp dtspc 6112/tcp
CDE subprocess control fs 7100/tcp Font
server
27
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Identifying Connections
Servers typically just listen for connections.
When they do, they listen only for connections to
their well-known ports (or predefined ports). A
client contacting a server initiates a connection
to that port. Since the client takes the
initiative, it must know both the IP address and
the port for that server. The server, on the
other hand, does not need to know the identity of
the client in advance. The server simply waits
for any client to initiate the connection, and it
responds to whichever IP address and port value
that the client has chosen for itself.
28
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Establishing Connections
A TCP connection begins its life when two systems
complete the connection establishment process.
This process identifies the connection to both
systems and prepares the connection for data
transfer.
TCP establishes connections with a procedure
known as a three-way handshake. Despite its name,
the three-way handshake usually consists of four
distinct events.
29
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Establishing Connections
passive connection request (listen)
active connection request
30
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Establishing Connections
Why three-way handshake the problem of delayed
duplicates
connection request
(traveling in the network)
connection request
acked
The three popped out later.
(traveling in the network)
message
acked
message
disconnect request
(traveling in the network)
disconnect request
acked
31
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Establishing Connections
Why three-way handshake the problem of delayed
duplicates
Simple but unsatisfactory solutions 1. Use
throwaway transport address Each time a
transport address is needed, a new, unique
address is generated 2. Use a connection
identifier Each transport protocol should
memorize obsolete connections
32
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Establishing Connections
Why three-way handshake the problem of delayed
duplicates
A better approach
Rather than allowing packets to live forever
within the subnet, we must devise a mechanism to
kill off very old packets that are still
wandering about.
If we can ensure that no packet lives longer
than some known time, the problem becomes
somewhat more manageable.
33
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Establishing Connections
Why three-way handshake the problem of delayed
duplicates
Packet lifetime can be restricted to a known
maximum using one of the following
techniques 1. Restricted subnet design 2.
Putting a hop counter in each packet 3. Time
stamping each packet
34
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Establishing Connections
Why three-way handshake the problem of delayed
duplicates
three-way handshake for connection establishment
Normal operation
CR(seqx)
CR(seqx) CC(seqy,ackx)
CC(seqy,ackx) Data(seqx,acky)
Data(seqx,acky)
35
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Establishing Connections
Why three-way handshake the problem of delayed
duplicates
three-way handshake for connection establishment
Old duplicate CR
OLD DUP
CR(seqx) CC(seqy,ackx)
CC(seqy,ackx) Rej(acky)
Rej(acky)
36
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Establishing Connections
Why three-way handshake the problem of delayed
duplicates
three-way handshake for connection establishment
Old duplicate CR
OLD DUP
CR(seqx) CC(seqy,ackx)
OLD DUP
CC(seqy,ackx) Rej(acky)
Data(seqx,ackz)
Rej(acky)
Guarantee that the sequence numbers do not repeat
within a reasonable time frame.
37
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Establishing Connections
Although connection establishment is part of
TCPs responsibility, the application protocols
must initiate it.
It is also possible for both applications to make
active requests, in which case, the connection
establishment still succeeds. When both systems
try to initiate a connection by sending
connection request packets, instead of sending
positive connection responses, each system merely
acknowledges each others connection request.
38
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Establishing Connections
39
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Transferring Data
Once TCP establishes a connection, it can begin
to use it, which means transferring data across
it. Of course, the whole point of connections is
to make this data transfer reliable. The key to
this reliability is sequence numbers.
TCP transfers application data by packaging that
data within a TCP packet. Most commonly, TCP
packets are called segments. In addition to the
data itself, segments contain sequence numbers.
40
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Transferring Data
Sequence numbers give every byte of application
data its own number. When packets arrive at their
destination, the receiving TCP can use these
numbers to reconstruct the correct order for the
data.
Data bytes 100-199
Data bytes 200-299
Data bytes 300-399
41
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Transferring Data
If TCP receives data with the same sequence
number, it recognizes that the data is
duplicated, and it discards the extra copies.
Similarly, if TCP finds gaps in the sequence
numbers, it realizes that it is missing some
data. It can then take appropriate steps to
recover that missing data. (Beware of the delay
duplicates.)
Note that sequence numbers are independent for
each direction in a connection.
42
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Acknowledgement
To recover missing data, the peer TCPs must
communicate directly with each other. After all,
the receiver knows that data is missing, but it
is the transmitter that has the data and needs to
send a new copy.
TCP exchanges the necessary information through
acknowledgements. When one TCP sends a packet to
the other, it may include an acknowledgement
number (piggyback). By including an
acknowledgement number, TCP says I have
successfully received all data up to (but not
including) the data with this sequence number.
43
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Acknowledgement
Data bytes 100-199
The next expected byte has sequence number 400.
Data bytes 200-299
Data bytes 300-399
Ack. 400
44
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Acknowledgement
Implications 1. Segment 200-299 must time-out
and retransmit (timers are needed) 2. Receiver
must have buffers to save segment 300-399. (How
many buffers are needed?)
Data bytes 100-199
Data bytes 200-299
Data bytes 300-399
Ack. 200
Data bytes 200-299
Ack. 400
45
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Flow Control
Sequence numbers also play a role in another
important function-flow control. Flow control
allows a receiver to limit the amount of data
that the sender transmits.
Flow control is an ongoing part of every
connection. As soon as TCP establishes a
connection, and throughout the connections life,
each system tells the other how much data it can
accept. It does so by specifying a window size.
46
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Flow Control
Ack. 400, window200
Data bytes 400-499
PC must stops here until further acknowledgements.
Data bytes 500-599
Ack. 600, window100
Data bytes 600-699
47
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Urgent Data
In addition to regular data, TCP understands the
concept of urgent data.
If the application has already sent regular data
on the connection, this urgent data will
inevitably take its place behind less urgent data
on the connection. TCP delivers data in sequence,
so it cannot do anything to give the urgent data
any special treatment. Instead, it lets the
application tells its peer that urgent data
follows. Presumably, when the receiver gets this
indication, it will process the regular data as
fast as possible in order to get to the urgent
information.
48
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Closing Connection
Releasing a connection is asynchronous and may
lose data.
DATA
DISCONNECT request
DATA may be lost after a disconnect request
49
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Closing Connection
An obvious solution is not to have either side
issue a T-DISCONNECT.request until it is sure
that the other side has received all data that
has been sent, and has no more data to send
itself.
I am done. Are you done too?
I am done too. Goodbye.
50
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Closing Connection
Problem How can the PC be sure that the last ack
packet is received by the workstation?
51
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Closing Connection
The two-army problem
How can the black armies synchronize their
attacks ?
B
B
W
52
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Closing Connection
The two-army problem
It can easily be proven that no protocol exists
that works.
1. Suppose that some protocol did exist. 2.
Remove the unessential messages until we are
left with a protocol that every message is
essential. 3. What happens if the final message
does not get through?
53
Chapter 7 Reliable Delivery with TCP
Connection-Oriented Operation
Closing Connection
timeout then delete connection
send DR start timer
n-retries then delete connection
DR arrives send DCstart timer
DC arrives send ACK delete con.
ACK arrives delete connection
54
Chapter 7 Reliable Delivery with TCP
TCP Specifications
This section only considers the requirements that
the TCP specification places on TCP programs. The
next section looks at different ways that TCP
implementations can adhere to the standard. Many
times, implementation details can have a major
effect on system and network performance.
All TCP packets have the same basic format. The
header that precedes application data is the same
for every type of TCP packet, from connection
requests to user data. To distinguish packets
with different functions, TCP employs different
settings of the control field.
55
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Sequence number for the first application data
byte (initial SN)-1 for SYN packet
When ack bit set, indicate the next SN expected.
Once TCP establishes a connection, it must
include this field in every packet.
56
Chapter 7 Reliable Delivery with TCP
TCP Specifications
The number of 32-bit words in TCP header
Indicate how many bytes of data the system can
accept (meaningful only when the ACK bit is set)
57
Chapter 7 Reliable Delivery with TCP
TCP Specifications
The sequence number, acknowledgement number and
window size constitute the TCP sliding-window
flow control.
The TCP sliding window mechanism operates at the
octet level, not at the segment of packet level.
Current window size7 bytes
Byte stream
1 2 3 4 5 6 7 8 9 10 11 ...
Sent and unacked
To be sent
Sent and acked
Cannot be sent until further ack
Each connection maintain three pointers.
58
Chapter 7 Reliable Delivery with TCP
TCP Specifications
TCP Control Field
(and window field)
59
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Pseudo header for computing checksum
TCP Checksum
6
60
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Urgent Pointer
When the urgent bit is set, the pointer
identifies where the urgent data end in the
application data.
urgent data ends at byte 1200
Byte 1000
61
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Urgent Pointer
Two things are significant about the urgent
pointer. First, it gives no indication of where
the urgent data actually begins. If it is
important, applications must determine this on
their own. Second, the urgent data may not be
included in the packet with an urgent pointer.
If, in the example, the data packet contained
only 100 bytes of data, then the urgent data
could conceivably be waiting for another packet.
The urgent pointers intent is simply to urge the
receiver to process data as fast as possible.
62
Chapter 7 Reliable Delivery with TCP
TCP Specifications
TCP Options
If the data offset has a value greater than 5,
then the packet includes TCP options.
Total option length including Kind and Length
63
Chapter 7 Reliable Delivery with TCP
TCP Specifications
TCP Options
Single byte option
64
Chapter 7 Reliable Delivery with TCP
TCP Specifications
TCP Options
End of Options instructs the recipient to stop
looking for additional options in the remaining
TCP header. Note that TCP does not have to use an
end of options in all packets. If the actual
options naturally end on a 4-byte boundary, then
TCP can simply conclude its header with those
options.
Data offset in 32-bit unit
Use end of options here
Last byte of options
65
Chapter 7 Reliable Delivery with TCP
TCP Specifications
TCP Options
No operation tells the recipient to ignore this
particular byte, but continue processing the
option field. The noop option lets TCP align
following options on a appropriate word
boundaries.
Maximum Segment Size option is used only during
connection setup. If present, it indicates the
largest packet size (in bytes) the sender is
prepared to receive. The maximum segment size
does not include the TCP header rather, it
refers only to application data.
66
Chapter 7 Reliable Delivery with TCP
TCP Specifications
TCP Options
The window scale factor supplies a multiplier for
the window field. Without a scale factor, the
window field simply specifies bytes. Because the
field has only 16 bits, TCP cannot specify a
window greater than 65535 bytes without this
option.
At first glance, 65535 bytes might seem like an
extraordinarily large window. However, on high
speed or long delay networks, this window size
can artificially and severely limit performance.
67
Chapter 7 Reliable Delivery with TCP
TCP Specifications
TCP Options
New York
Tokyo
68
Chapter 7 Reliable Delivery with TCP
TCP Specifications
TCP Options
With a window size of 65535 bytes, the greatest
throughput possible over the connection is 65535
bytes per 100 milliseconds (5.2Mbps).
69
Chapter 7 Reliable Delivery with TCP
TCP Specifications
TCP Options
The culprit in this case is not simply the delay.
Rather it is the product of the delay and
bandwidth of the path. If, for example, the
Tokyo-New York link relied on a T1 line with 1.54
Mbps, TCP throughput would be limited by the bit
rate, not the window size.
70
Chapter 7 Reliable Delivery with TCP
Assume a standard 65535-byte TCP window
TCP Specifications
TCP Options
71
Chapter 7 Reliable Delivery with TCP
TCP Specifications
TCP Options
The window scale option provides a way to
overcome the throughput limit. The scale option
only appears in connection requests and
responses, and both systems must agree to use it.
When the option is in use on a connection, any
window size fields that appear in packets are
multiplied by 2k, where k is the shift count
appeared in the option.
TCP window scale option format
72
Chapter 7 Reliable Delivery with TCP
TCP Specifications
TCP Options
Even though the window scale option could hold a
value as large as 255, TCP limits the valid
values to be between 0 and 14 (inclusive). The
upper limit ensures that the maximum difference
between the sender and receiver can be no greater
than 231. Without such a limit, TCP might not be
able to tell when the 32-bit sequence number had
rolled over from 231-1 back to 0. If TCP receives
a window scale option greater than 14, it treats
it as if it were 14.
The window scale option allows TCP to use windows
as large as 16 million bytes. That window does
not artificially limit a transpacific fiber
unless its bandwidth exceeds 1.3 Gbps.
73
Chapter 7 Reliable Delivery with TCP
TCP Specifications
TCP Options
sender
receiver
Sending window 0230-1
receiving window 0230-1
Data arrived
Ack lost
receiving window 230231-1
Sending window 0230-1
Therefore, maximum window scalelt15.
74
Chapter 7 Reliable Delivery with TCP
TCP Specifications
TCP Options
The timestamp option is the only option that has
meaning in regular data packets. All of the other
TCP options are only significant in connection
requests and responses. This option provides a
way for TCP implementations to continuously
monitor the round-trip time for a connection.
Two noop options before timestamp option for
alignment
75
Chapter 7 Reliable Delivery with TCP
TCP Specifications
TCP Options
The first value is the primary timestamp value.
When a system builds a packet for transmission,
the value represents the local time within that
system.
The TCP specification places few requirements on
this timestamp value. It does not have to
represent seconds, minutes, or some other
standard time reference. It is sufficient when
the sender merely uses a value that it guarantees
will not decrease at any point in the future.
76
Chapter 7 Reliable Delivery with TCP
TCP Specifications
TCP Options
The second timestamp value is valid only when it
appears in acknowledgement packets, where it is a
copy of the timestamp that was contained in the
data packet being acknowledged.
For example, TCP receives a data packet with a
timestamp value of 500. When the system accepts
that packet, it will return an acknowledgement
packet to the original sender. Within that
acknowledgement packet, it can use its own time
reference for the primary timestamp value. The
timestamp echo value, however, should be 500.
77
Chapter 7 Reliable Delivery with TCP
TCP Specifications State Transition Diagram
Event Action
78
Chapter 7 Reliable Delivery with TCP
TCP Specifications State Transition Diagram
79
Chapter 7 Reliable Delivery with TCP
80
Chapter 7 Reliable Delivery with TCP
81
Chapter 7 Reliable Delivery with TCP
TCP Specifications
82
Chapter 7 Reliable Delivery with TCP
TCP Specifications
FTP
Establishing Connections
Data will start at 10001
(SYN1)
83
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Establishing Connections
Since packets can survive on a network after
their connection closes, TCP must take care in
choosing an initial sequence number. It must be
sure to select a number that can no longer exist
(from a previous connection) on the network. The
TCP standard recommends basing initial sequence
numbers on a clock that increments about every
4ms. If a system loses the value of this clock
(perhaps because of a crash), it should avoid
sending any TCP packets for several minutes after
it restarts. The delay is called quiet time.
84
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Establishing Connections
Both the window scale and timestamp options were
absent from the original TCP standard. Many older
TCP implementations, therefore, may not
understand them. To interoperate with old
implementations, a system only uses these options
if its peer indicates it can understand them.
TCPs indicate their support for options by
including them in connection packets. If a system
includes an option in its connect request, but
the peer does not include the same option in the
connect response, the system cannot use the
option on the connection.
85
Chapter 7 Reliable Delivery with TCP
TCP Specifications
A window size of 8192 bytes
Establishing Connections
Data will start at 30001
(ACKSYN)
86
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Establishing Connections
The above example assumes that the system
receiving the connection request will accept that
request. If, instead, the recipient does not
accept the connection, it refuses the connection
by generating a reset packet.
The final step in the three-way handshake is an
acknowledgement of the connect response.
87
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Establishing Connections
(ACK)
88
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Establishing Connections
When the acknowledgement packet makes it to its
destination TCP, the three-way handshake is
complete. At this point, the connection is
established.
Though the examples do not show it, the
acknowledgement, as well as the connect request
and response packets, can carry application data.
TCP cannot deliver that data to the application,
however, until connection establishment is
complete. In most cases, only the final
acknowledgement actually carries data.
89
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Establishing Connections
90
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Establishing Connections
91
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Resetting a Connection
PC knows it is wrong since the correct ack number
should be 10001.
92
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Resetting a Connection
RST bit set in the control field
93
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Resetting a Connection
The rules That TCP follows when considering
whether to send a reset
94
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Resetting a Connection
The rules that determine when a reset is valid
95
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Resetting a Connection
If a reset is valid, TCP responds to it in one of
several ways.
96
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Transferring Data
Ordering Data
TCP numbers every byte of data that it transfers.
The TCP sequence numbers can range from 0 to
232-1. The natural question that arises, then, is
what about byte number 4,294,967,296 (232)? TCPs
answer is to start over again. Sequence numbers
wrap around in this way as many times as
necessary over the life of a connection.
Of course, wrap around brings up another
question. How does TCP tell an old byte number
0 from a newer one?
97
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Transferring Data
Ordering Data
TCP uses a special rule to determine the order of
two sequence numbers, A and B. A is considered
less than B if 0lt(B-A)lt231.
For low-and moderate-speed networks, this special
test does not create a problem. On such networks,
it takes a long time to reach the wraparound
point. And, since all packets have some
reasonable lifetime, there is generally no
question about whether a packet that is
demonstrably still alive is old or new.
98
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Transferring Data
Ordering Data
99
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Transferring Data
Ordering Data
As the above table shows, it is not likely that a
packet can survive on an ISDN or Ethernet network
long enough to cause confusion. With the
higher-speed networks, however, particularly ATM,
the wraparound time becomes a major cause for
concern.
It is quite possible for an occasional packet to
get stuck somewhere for six or seven seconds.
When that packet arrives later at its
destination, the receiver will not be able to
determine that the packet is old just by looking
at the sequence number.
100
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Transferring Data
Ordering Data
To operate effectively in high-speed networks,
TCP uses the timestamp option. This option adds a
32-bit timestamp to each packet. The value must
increase monotonically, and it must increment at
a rate between once a millisecond and once a
second.
As long as the network speed is less than 17Gbps,
it is not possible for the sequence number to
wrap around before its timestamp increments at
lease once. Furthermore, the timestamp value
itself cannot wrap around in less than 24 days.
101
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Transferring Data
Ordering Data
Given these limits, TCP can safely use the
timestamp as a 32-bit extension of the sequence
number. Together, the timestamp and sequence
number can act as a single 64-bit quantity.
Of course, this combination is only appropriate
for deciding the relative order of two packets.
It is not valid for sizing windows or building
acknowledgement.
102
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Transferring Data
Ordering Data
Compare timestamp first, then compare sequence
number AltB if 0ltB-Alt231
103
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Transferring Data
Flow Control
With flow control, a system regulates the amount
of data that its peer transmits. Such regulation
can prevent the peer from sending more data than
the local system can comfortably accept.
TCP flow control is based on a sliding
transmission window. With every packet that
contains an acknowledgement number, TCP also
includes a window size. Those two numbers define
the limits of what the system is prepared to
receive.
104
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Transferring Data
Flow Control
Advertise a window from 1000 to 2023
105
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Transferring Data
Flow Control
The sender knows that transmitting any data prior
to byte number1000 is unnecessary. The receiver
has already accepted all such data. Furthermore,
the peer knows it cannot send data beyond byte
number 2023. Such data is outside the window, and
will be ignored by the receiver.
To work with the flow control window, TCP
maintains three values for each connection. These
values regulate how much data TCP can send.
106
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Transferring Data
Flow Control
These three values are the last data sent but not
yet acknowledged (SndUna), the next new data byte
to send (SndNxt), and the windows limit
(SndUnaSndWnd). The intermediate value SndWnd is
the senders view of the window, as determined by
the latest acknowledgement it has received.
107
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Transferring Data
Flow Control
108
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Transferring Data
Acknowledgment and Retransmission
When TCP receives a packet with application data,
it must decide how much of the data, if any, is
valid. To make that determination, TCP relies on
two values that it maintains for each connection,
the next byte expected (RcvNxt) and the flow
control limit (RcvNxtRcvWnd).
109
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Transferring Data
Acknowledgment and Retransmission
110
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Transferring Data
Acknowledgment and Retransmission
When the system receives a packet, it subjects
that packet to tests that determine the packets
validity.
At least some of the data is valid
111
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Transferring Data
Acknowledgment and Retransmission
When TCP receives valid data that is contiguous
with the last byte it acknowledged, it updates
the acknowledgement number in subsequent packets
to its peer. If there is a gap between the new
data and the last acknowledgement, then the
acknowledgement number cannot be advanced. In
fact, in this case, TCP cannot even deliver the
data to its application.
112
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Transferring Data
Acknowledgment and Retransmission
When TCP returns an acknowledgement to its peer,
it is normally expected to include a timestamp
option in that packet. (Timestamps are not
included if the systems did not negotiate their
use during connection establishment.) That option
includes an echo of the timestamp in the received
packet. In most cases, deciding which value to
echo is straightforward. TCP simply copies the
timestamp value from the latest received packet.
Some situations introduce complications, however.
113
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Transferring Data
Acknowledgment and Retransmission
TCP maintains two additional values for each
connection. The first value is normally the most
recent timestamp value received, TSRecent. This
value is what TCP echoes in timestamp options
that it sends. The second value is the last
acknowledgement number sent, LastAck. Often, this
value is the same as the next byte expected
(RcvNxt), but some TCPs may choose not to
acknowledge every packet immediately. In such
cases, RcvNxt may temporarily advance ahead of
LastAck.
114
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Transferring Data
Acknowledgment and Retransmission
When a system receives a packet, it performs the
following test.
If LastAck does fall within this range, then TCP
saves the packets timestamp value in TSRecent.
This value is what it echoes in the next packet
it sends.
115
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Transferring Data
Closing Connections
116
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Transferring Data
Closing Connections
When the packet exchange is complete, the two
systems take different approaches to deleting the
connection. The workstation does so as soon as it
receives tha PCs final acknowledgement. The PC
defers the actual deletion for a short period of
time, in case there are any stray packets from
the connection still surviving on the network.
A simultaneous close occurs when both
applications initiate a close at the same time.
In this case, both systems should delay before
deleting the connection.
117
Chapter 7 Reliable Delivery with TCP
TCP Specifications
Transferring Data
Closing Connections
118
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Path MTU Discovery
In IPv4, routers as well as hosts could fragment
datagrams. Instead, IPv6 expects its users to
learn the MTU size for the path and, once it is
known, restrict their data packets so that they
fit within that limit.
To meet this expectation, TCP must do more than
simply honor the maximum segment size option it
receives from its peer. It must determine the
true segment size for the connection.
119
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Path MTU Discovery
Effective MSSmin(MSSrcvd20,MSGmax)-TCPhdr-IPopts
120
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Out-of-Order Buffering
Dont discard the data received out of order.
Although this approach works, it carries a high
penalty. TCP implementations should always strive
to save out-of-order data. Once the missing
packets arrive, TCP can deliver the out-of-order
data to its application straight from local
memory.
121
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Zero Window Probes
TCP does not guarantee the reliability of
acknowledgements it does not retransmit packets
that contain only acknowledgements.
Normally, this behavior does not pose a serious
problem. If an acknowledgement is lost, the peer
will eventually retransmit the data that the lost
packet acknowledged,
122
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Zero Window Probes
123
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Zero Window Probes
Receiver is congested
PC does not know that window is reopen.
124
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Zero Window Probes
To break this deadlock, the PCs TCP must take
special actions. Whenever the window closes
completely, TCP periodically sends a data packet.
Of course, it expects its peer to reject the data
packet, since the packet is outside of the
window. This rejection, which will come in the
form of an acknowledgement packet, will either
confirm that the zero window still exists, or
effectively retransmit the lost acknowledgement
that should have opened the window.
The extra packets that the PC sends are known as
zero window probes.
125
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Zero Window Probes
Reopening a closed window with zero probes.
126
Chapter 7 Reliable Delivery with TCP
200
Implementing TCP
200
Silly Window Syndrome
200
50
Because at one point (A in the figure) the sender
sends a small packet, it will be forced in the
future to break its data into more packets of
this size.
150
200
200
50
127
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Silly Window Syndrome
To avoid the silly window syndrome, TCP requires
specific behavior in both the sender and
receiver. For the receiver, TCP avoids
advertising an updated window until the update is
larger than some reasonable value. Formally, that
reasonable value is defined to be the minimum of
two quantities-the effective maximum segment size
(MSS) for the path and a fraction (typically
half) of the actual buffer space available.
128
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Silly Window Syndrome
Refrain from updating the window
129
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Silly Window Syndrome
adjustable
0.1 to 1 seconds
U Usable WindowSndUnaSndWnd-SndNxt D the
amount of data available to send Max(SndWnd) the
maximum window seen on the connection so far
130
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Slow Start and Congestion Avoidance
131
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Slow Start and Congestion Avoidance
Will lead to congestion collapse
132
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Slow Start and Congestion Avoidance
Slow start addresses one of the most common
sources of increased traffic (and resulting
congestion) in a network-the start of a new
connection. If forces a new connection to
gradually test the capacity of its path and not
overwhelm it with a sudden increase in data.
Slow start requires that TCP maintain an
additional value for each connection. That value
is the congestion window. It starts at one
packet, and TCP increments it by one each time it
receives an acknowledgement.
133
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Slow Start and Congestion Avoidance
When a TCP connection begins, the congestion
window is one. TCP, therefore, sends a single
packet to its peer. When that packet is
acknowledged, TCP increments the congestion
window to two, and sends two packets. As the peer
acknowledges each of these two packets, the
congestion window increases to three and then
four.
Slow start continues in this fashion until TCP
gets an indication that it has pushed matters too
far. That indication is retransmission timeout
for a packet.
134
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Slow Start and Congestion Avoidance
Once congestion appears, TCP takes three
actions. 1. It doubles the value it is using for
retransmission timeout on the connection. 2. It
remembers the value of the congestion window when
congestion appeared. 3. TCP begins the slow start
process again by lowering its congestion window
to one.
135
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Slow Start and Congestion Avoidance
As slow start naturally increases the congestion
window again, TCP modifies its behavior when the
window reaches half of the value at which
congestion appeared. At that point, instead of
incrementing the window with each
acknowledgement, it increments the window (by
one) with each window full of acknowledgements.
136
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Slow Start and Congestion Avoidance
137
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Slow Start and Congestion Avoidance
A key element of successful congestion avoidance
is a finely tuned retransmission timer. Its
timeout value must accurately reflect the
uncongested round-trip time for the connection.
If the timeout is too short, it will expire
needlessly. On the other hand, if it is too long,
it may fail to detect the onset of congestion,
and prevent TCP from taking appropriate steps to
reduce its load.
138
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Slow Start and Congestion Avoidance
The algorithm currently deemed the best at
setting timeouts relies on sampling the actual
round-trip time for packets on the connection.
TCP implementations should only sample those
packets that are acknowledged without a
retransmission.
RTT a sample of round-trip time mRTT mean,
sRTTstandard deviation
139
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Delayed Acknowledgement
Even when a system has no data to send on a
connection, it must still acknowledge data that
it receives from its peer. The acknowledgement
packets that it uses carry no application data
themselves, and so, in some way, they waste
network bandwidth. To minimize this wasted
bandwidth, a TCP implementation need not
acknowledge every packet as soon as that packet
arrives. Instead, the system can delay the
acknowledgement for a brief period. (no longer
than 0.5 seconds)
140
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Header Prediction
With header prediction, when TCP receives a
packet, it predicts, in advance, the next
packets likely header. Then, when the next
packet arrives, TCP merely has to check it
against the early prediction. If the prediction
was correct, TCP immediately accepts the packet
as valid, avoiding the lengthy checks it might
otherwise make.
141
Chapter 7 Reliable Delivery with TCP
Implementing TCP
Prediction11024
Header Prediction
Given the left packet, what can TCP expect to see
in the next packet it processes?
Cannot predict