KRONE: 800-775-KRONE www.kroneamericas.com www.truenet-system.com
No part of this document may be reproduced without permission ©2001 KRONE, Inc.
The Effect of Errors on TCP
Application Performance
in Ethernet LANs do to
application performance?
This question has arisen time
and time again since the
KRONE
®
TrueNet
TM
structured
cabling system was launched.
The simple answer is that
errors can degrade application performance; the com-
plicated answer is that the degradation is dependent on
how the errors effect TCP. How TCP works, and what can
happen to TCP in the face of errors is the subject of this
paper. KRONE enlisted the help of an independent
consultant, Dr. Phil Hippensteel, to study this topic and
provide his evaluation of what Ethernet errors would do
to application performance. The following paper presents
Dr. Hippensteels findings.
--Editor
In this paper we will discuss the relationship between
errors that occur in networks and their impact on the
performance of applications that run over Transmission
Control Protocol (TCP). While many individuals in the
industry give the impression that they understand
network errors and error detection and while much has

request, the message flows down through what is
referred to as the protocol stack. This is illustrated in
Figure 1. In most implementations, each of the layers
shown creates one of the headers in the encapsulated
message.
As a specific example, suppose a client device such as a
PC makes a request of a web server to retrieve a web
page. The application program interface (API) Hypertext
Transfer Protocol (HTTP) would formulate the request in
this format:
HTTP Header HTTP Message (response)
Figure 1
This message and header would be given to TCP. TCP
would add its header and pass it to the Internet Protocol
(IP). IP would add its header and pass it to the network
interface card (NIC), for instance an Ethernet card.
Finally, the Ethernet card would be responsible for
sending the total Ethernet frame onto the network.
That frame would look like this:
KRONE: 800-775-KRONE www.kroneamericas.com www.truenet-system.com
No part of this document may be reproduced without permission ©2001 KRONE, Inc.
The most widely
used connection
oriented protocol
is TCP.
When this frame arrives at the receiver, each layer
processes its part of the message. In a manner of
speaking, the message filters up through the protocol
stack to the application.
Next, lets focus on the two types of protocols.

that TCP will deal with the basic features of a connec-
tion-oriented exchange.
Error Detection in Packet Networks
There are three types of error detection schemes that
we will study. The first of these is the detection of an
individual bit that is corrupted. This is usually the
responsibility of the receiving interface card. The
metric that is used to describe the rate at which erred
bits arrive is the bit error rate (BER). When a test is run
to determine the BER, it is called the bit error rate test
(BERT). When the physical level specification for a link
is written, it frequently specifies values such as 10
-9
or
10
-10
. If the BER were specified as 10
-9
, it would mean
that the probability that a single bit would arrive in
error is one in one billion. This figure cannot be used
accurately to describe the probability that a data
frame will be corrupted upon arrival. The second
error detection method we will review is specifically
intended to provide a metric for the probability that a
data frame is corrupted. This technique is called the
cyclic redundancy check (CRC). This is a highly reliable
method that has become almost the exclusive means
by which network interface cards check incoming
data frames. Finally, well investigate the error

corrupted is neither the BER nor twice the BER. In a
similar manner, we can show that the probability of at
least one bit in a three-bit frame would be corrupted
is 1-(1-p)
3
=1-(9.)
3
=0.271. For interested readers, The
appendix contains a more sophisticated discussion of
the relationship between BER and the block error
rate.
KRONE: 800-775-KRONE www.kroneamericas.com www.truenet-system.com
No part of this document may be reproduced without permission ©2001 KRONE, Inc.
...as a matter of
practice, think of
CRC-32 as
practically
infallible.
The calculation of the block error rate for local area
networks such as Token Ring, Ethernet and FDDI uses
the cyclic redundancy check algorithm. Figure 2
illustrates how it works:
Suppose a frame is to be transmitted by an Ethernet NIC
in a client station across a twisted pair link to a hub and
on to the NIC of a server. The NIC in the client will divide
the entire message by a 32-bit pattern (dictated in the
IEEE 802.3 specification). It will ignore the dividend but
insert the remainder as the last field in the Ethernet
frame. This field is called the frame check sequence. It
can be established mathematically that the remainder is

parity check techniques, the sender sends a group of bits
and adjusts the last bit in the block so that the total
number of bits in the block is either odd or even,
whatever has been agreed upon in advance by the
transmitting and receiving stations. We can visualize the
message listed character by character vertically, like this:
Character 1 1 0 0 0 0 0 0 0
Character 2 0 0 0 0 0 1 1 1
Character 3 1 0 1 0 0 0 0 1
Character 4 0 0 0 1 0 1 0 1
Character 5 0 0 1 0 0 1 0 1
Character 6 0 0 0 1 0 0 0 0
Character 7 0 0 1 1 1 1 0 1
Character 8 0 0 0 1 0 1 1 0
Character bits
In this illustration odd parity is being used in the rows. So
the sender adjusts the eighth position to make sure that
each row contains an odd number of ones. For example,
in row one, the character is represented by the pattern
1000000. Since that contains a single one, which is an
odd number, the eighth position is made zero. Hence, the
full eight-bit pattern still contains an odd number of ones.
However, in row two, the character is represented by the
pattern 0000011. Since that pattern contains two ones,
which is an even number of ones, the eighth position is
adjusted to one, giving a total of an odd number of ones
in the pattern. Today parity checking is rarely used as the
sole error detection scheme except in low speed links
such as dial-up lines. Parity checking is too easy to
defeat; if two bits in a character are reversed during

calculation is performed on the complete message
block.
There are some interesting observations we can make
at this point. First, the protocols implemented in
software may calculate a checksum and transmit it
whether or not they are connection-oriented. Also, the
checksum doesnt need to be quite as robust as CRC-32
because it is almost always a redundant check. The
receiver assumes that the NIC or its driver would have
dropped the frame had it contained an error. The IPX
protocol is so confident that CRC-32 will detect the
error that it sets the checksum field to all ones as a
means of disabling it.
We are particularly interested in TCP/IP environments,
so how are these techniques used in such an environ-
ment? Ethernet NIC cards use CRC-32. If the receiver
successfully passes the data frame to the IP protocol, IP
will calculate the checksum value based only on the IP
header. Since IP is connectionless, the assumption is
made that some other protocol will be concerned with
the integrity of the data field (which will be inspected
by TCP or UDP.) On the other hand, TCP is connection-
oriented. So, the application is dependent on TCP to
provide error-free data. Therefore, TCP uses the IP
addresses, the protocol identifier field, the segment
length field, and the data field as the basis for its
checksum calculation. This combined set of fields is
called the pseudo-header and data.
Recall our conclusion from near the beginning of the
paper: connectionless-oriented protocols depend on

· Providing flow control so that neither application
will transmit information faster than its partner
can receive and process it. i.e. the sender should
not overfill the receivers buffer.
· Providing a means by which the packets can be
sequenced in order that they can be correctly
organized for delivery at the receiving end.
· Detecting that errors have occurred in the
network and reacting appropriately.
· Adjusting to conditions in the network to allow for
a high level of throughput.
Well discuss each of these in some detail. However,
first we need to actually look at the fields in the TCP
header. These are shown in Figure 3:
KRONE: 800-775-KRONE www.kroneamericas.com www.truenet-system.com
No part of this document may be reproduced without permission ©2001 KRONE, Inc.
Figure 3
Since we need to understand most of the fields in the
TCP header, we will review all of them for the sake of
completeness. The combination of the TCP header and
its data is called a TCP segment. Port numbers are used
to identify the sending and receiving application
processes. They are not physical ports, rather they are
identifiers that indicate the specific application program
that sent or is to receive the TCP data. Port numbers up
to 1023 are referred to as well-known. This simply
means they are registered with the Internet committee
responsible for tracking Internet numbers; it also means
that everyone agrees on the meaning of these numbers.
For example, 25 is the port number for SMTP, the Simple

can use the sequence numbers to determine how
many bytes were sent in the first segment. The
receiver can also tell the order of the segments since
the sequence numbers always increase in value. If a
receiver subtracts the first sequence number it
receives from the second sequence number it
receives, the data field should contain that number of
bytes. If it does not, the receiver knows that one or
more segments were lost or dropped.
The acknowledgement number is returned to the
sender to indicate the sequence number it expects to
receive next. In the illustration in the previous
paragraph, the receiver would return the
acknowledgement number 17,334 to indicate that it
received the frame with sequence number 17,234
and 100 bytes of data. Figure 4 shows how this is
often illustrated:
Figure 4
The first packet will contain 100 bytes of data. The
returned packet containing the acknowledgement
number may or may not contain data. Usually it does
not. In other words, most often the
acknowledgement segment will contain only a TCP
header encapsulated in IP and the data link informa-
tion such as Ethernet.
The field labeled Head Length in Figure 3 indicates
how many 32-bit blocks (rows in the diagram) are in
the TCP header. By reading this field the receiver can
determine whether the options block(s) contain any
information. The options block is the last row in the