Tài liệu KRONE - the effect of Errors in TCP applications performance (full) pdf

The sequence number is used to make it possible for the receiver to determine the order in which the TCP segments were sent.. When a transmit-ting TCP entity starts to deliver data bytes

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

been published on the performance issues of TCP, few

attempts have been made to tie these two topics

together However, this topic is important A vast

number of applications use TCP, including most

transac-tion-oriented systems and virtually all web–enabled

processes Our purpose will be to provide some insight

into how applications are affected by errors, particularly

at the physical level, and to illustrate this through case

studies

We will begin by developing some background We will

study how a typical TCP message is encapsulated as well

as the differences between connection-oriented

protocols and connectionless-oriented protocols We will

investigate TCP and the User Datagram Protocol (UDP),

the two protocols nearly all applications use to

communi-cate Then, we’ll review the three classes of errors and

how they are detected Once this background has been

introduced, we’ll study how TCP operates in some detail

Some case studies will be used to illustrate these

W H A T

C A N

E R R O R S

concepts because they are the most difficult that will be covered We will conclude the paper with a summary and some observations about how to control errors in your network

Background Information

Messages sent from application to application in packet data networks such as LANs and WANs are encapsu-lated For example, as a server responds to a client 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:

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

Connection–oriented protocols are sometimes called reliable protocols This is because they make provisions for important functions to be conducted; functions that are essential so that the data will arrive in a way the receiver can use it The four key functions imple-mented by a connection–oriented protocol are: formal set-up and termination of the session, flow control, sequencing and error detection The most widely used connection-oriented protocol is TCP By comparison, connectionless-oriented protocols, such as IP and UDP usually make no provision for all of these features to be implemented Such protocols are sometimes called unreliable because they depend on a reliable protocol

to carry out these functions For example, when IP and TCP are used together, IP depends on TCP to handle flow control and sequencing However, in some cases,

a connectionless protocol will implement one or two of the functions

One of the most important concepts in data communi-cations is how connection and connectionless protocols are related

As a data message is created, an assumption is made that if a connectionless-oriented protocol is used, a higher layer will be connection-oriented That is, at the receiving end, if a lower layer protocol is connectionless,

a higher layer protocol will need to provide the connection-oriented functions

As an illustration of this, in the example of the web client-server interaction above, Ethernet and IP operate

in a connectionless fashion Therefore, it is assumed 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 detection technique usually used in software Most protocols such as TCP, UDP and IP include such a value

in their header and call it the checksum A variety of techniques are used to calculate it but we will review only one of the most commonly used procedures

To determine whether a physical link supports the specified BER, normally a test device sends a stream of bits to a receiving test device The receiving test device knows the pattern that was transmitted and is therefore able to determine which bits were corrupted during the transmission In nearly all instances, an output screen shows the number of bits transmitted, the number corrupted and the BER As pointed out above, the BER should not be applied to blocks of data A simple example should illustrate why this is the case Suppose that p=BER= 10-1 or 10% Although this is unusually high, it will help illustrate the point If a block of just two bits were transmitted, the likelihood that a block or frame would arrive

corrupted would be:

P(at least one bit is corrupt)

=1 - P(no bits are corrupted)

=1 - P(both bits arrive uncorrupted)

=1-(1-p)2= 1–(.9)(.9)= 1–0.81= 0.19 (19%) P( ) is used to indicate the “probability that.” Note that the probability that a two-bit block will be 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

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 always 32 bits (four bytes) in length When the frame arrives, the server NIC will repeat the division using the same IEEE specified divisor It subtracts the received remainder from the calculated remainder to determine

if the result is zero If it is zero, the transmitted and calculated remainders must have been the same

Consequently, it concludes that the transmitted message had no errors Otherwise, the NIC will record in a register on the card that the frame was received with

an error It is the responsibility of the NIC driver to react

to this indication In almost all cases, the driver will discard the frame However, it may report this error to the layer three protocol This issue is protocol depen-dent and we will discuss it later in this paper

CRC is highly reliable For example, the technique used

in Ethernet and token ring, called CRC-32 will detect:

· All single bit errors

· All double bit errors

· All odd-numbered bit errors

· All burst errors with length under 32

· Most bit errors with length 32 or over

This last bullet is very conservative The probability of a

burst error of length 32 or over is extremely small, so it is virtually impossible for this to occur Consequently, as a matter of practice, think of CRC-32 as practically infallible

As previously indicated, calculating a checksum may follow one of many specific procedures However, most follow a pattern that involves doing some form of parity checking with redundancy For example, in conventional 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 transmission, the scheme fails to detect the error

In order to add redundancy to the parity scheme, an additional algorithm is introduced Before the sender transmits this block of eight characters, it will perform a binary addition down the columns using a technique called 1s-complement sum It will invert that result (switch zeroes and ones), and insert the result as the block check character (BCC) We do not need to be concerned with the details of the 1s-complement sum process here By appending the BCC to the block, we will

Figure 2

have the result shown below The calculated BCC is

inserted in the checksum field in the data packet and

transmitted to the receiving station

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

When the receiver gets the message block, it will

perform a similar calculation While this technique isn’t

as foolproof as CRC-32, it is highly reliable Normally,

the entire message is appended with additional fields

such as network addresses Then the checksum

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

connection-oriented protocols to provide the reliability that they cannot System designers assume that if a protocol is connectionless, a connection-oriented protocol will process the packet to provide the integrity that the receiving application expects This is the case with error checking Refer again to Figure 1; in a situation where a TCP application is being used, if a frame error occurs at the Ethernet layer in the physical network, TCP will have the responsibility to deal with detecting this and taking appropriate action In the section on TCP perfor-mance, we’ll deal with how this occurs Specifically, if the data frame arrives and is dropped by the NIC driver, IP will never know it TCP will have to discover that the frame was dropped and react appropriately While a study of real-time applications, such as IP voice and video, is beyond the scope of this paper, in such an environment the responsibility for responding

to errors is pushed even higher Such applications often replace TCP with UDP UDP is connectionless,

so reacting to Ethernet errors would be handled by higher-level protocol, either the application program interface or the application

TCP Operation

Since TCP is a connection-oriented protocol, let’s review some of the key functions it is responsible for implementing These include:

· Formally establishing and terminating a session between the two applications that wish to communicate

· 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:

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

Mail Transport Protocol 80 is used for the web protocol

HTTP, mentioned earlier The server end of a connection

will normally use a well-known port The client will use

an arbitrary port number The port numbers above

1024 and below 65,536 are available to be defined as

necessary and are referred to as non-well-known ports

The sequence number is used to make it possible for the

receiver to determine the order in which the TCP

segments were sent It is assumed that this is the order

in which they are to be delivered However, it is possible

that the packets may have followed different physical

paths through the packet network While a detailed

analysis of a packet arriving out of sequence is beyond

the scope of this paper, later we will explain essentially

how TCP deals with it in the discussion of Figure 7

Also, some packets may get lost or become corrupted

and therefore would be dropped by a NIC along the

way The sequence numbers can also be used by the

receiver to detect missing segments When a

transmit-ting TCP entity starts to deliver data bytes, it will include

a value (up to thirty-two bits in length) called the initial

sequence number (ISN) in the sequence number field

This value is the number it associates with the first byte

in the transmitted segment For example, suppose there

are 10,000 bytes to be transmitted and the ISN is

17,234 If 100 bytes are sent in the first segment, the

last byte, would correspond to the tag 17,333

The next frame sent will contain the sequence number 17,334, exactly one hundred higher than the previous sequence number In this way, the receiver 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 diagram, just before the data row Normally, the header length has the value 5 (meaning no options are included) The reserved field is not used There are six code bits Each is read independently and is sort of an “on-off” switch to indicate a certain state

We are interested in only the last two bits called the SYN and FIN bits, respectively Consequently,

for our purposes the code field looks like this:

The second part of the diagram shows how the code

bits would be set when one of the TCP entities wants

to indicate the end of the session to the other TCP

entity The FIN bit is set to the value one or

“turned-on.” The window size, sometimes just called the

window, is the number of bytes the sending station has

in its buffer to accept return messages That is, it is an

announcement to the partner station about the

sending station’s ability to receive messages from that

partner If it should insert the value zero in this field, it

is declaring that temporarily it cannot receive messages,

most likely because it is busy trying to process previously

received messages that are already in its receive buffer

A window value, often called a window advertisement,

is included in every segment header, including simple

acknowledgements In this manner, each of the two

stations can measure the ability of the other to accept

its messages Initial window sizes commonly used are

8k and 16k bytes

The checksum field is the field in which the sender

indicates the result of its 1s-inversion calculation on the

pseudo-header and data This was described in the

section on error detection

The Three-Way Handshake

In order to establish a connection between stations A

and B, the A will send a segment to B with a header

that has these characteristics:

· It contains an initial sequence number (ISN)

· The acknowledgement number is zero

· The target port number is included to indicate the

target application process

· The SYN bit is set (meaning it has value one.)

This segment will contain no data If the target B

wishes to continue to establish the connection, it will

return a TCP segment with a header that has these

characteristics:

· It contains its ISN

· The acknowledgement value is equal to the

received sequence number + 1

· The SYN bit is set

· The port numbers are listed in the original request with source and destination reversed

This segment will also contain no data Finally, to bind the understanding A will send a third segment with a header that has these characteristics:

· It will contain its ISN +1

· It will include B’s transmitted sequence number +1

as its acknowledgement number

This segment may contain data that A wishes to transmit to B

This exchange to establish the connection is referred

to as the three-way handshake It is usually very easy

to detect using a protocol analyzer You simply watch for the SYN bit to be set and for the first of the three segment headers to have an acknowledgement value

of zero

As part of the session establishment, the two stations often agree on the maximum segment size that can

be transmitted in each direction This maximum segment size (MSS) is negotiated by including it as an option in the first segment transmitted If the other station doesn’t agree to the requested size, it simply doesn’t complete the three-way handshake In an Ethernet environment, the MSS is often 1460 bytes, reflecting the fact that 1460 bytes of data plus the 20 bytes in each of the IP and TCP headers and the 18 bytes of Ethernet header and trailer will total 1518 bytes This is the maximum size of an Ethernet frame While we will not describe the session termination process in detail, it is sufficient to mention that it is similar to the three-way handshake except that four segments are exchanged One segment is sent in each direction with the FIN bit set

With this understanding of the header fields, we are nearly prepared to study TCP performance First however, we will investigate a normal transfer of data from Station A (a web server) to Station B (a web client) This is illustrated in Figure 5 The following assumptions are being made:

· The MSS is 1460 and Station A sends that maximum in each segment The 1460 reflects the fact that 58 bytes are reserved for the TCP, IP and Ethernet headers and trailers

· The ISN for the server is 10,000.

· The sender’s buffer window size is initially 8k

· Station A’s application has a total of 8,000 bytes to transmit

· The session has already been established with a three-way handshake

Figure 5

The server transmits a single segment of 1,460 bytes It does this due to a widely endorsed strategy called slow-start This algorithm is used because the sender doesn’t know anything about the congestion or speed of the network If it were to burst a large number of segments onto the network it could cause congestion

As it receives acknowledgements, it assumes this is evidence that congestion is not a problem and gradually increases the number of segments that it transmits as a group

The client receives this segment and indicates it by the acknowledgement number 11,460; the byte it expects

to receive next Next the server sends two segments, each containing 1,460 bytes Since the receiver normally does not acknowledge a single segment immediately, it receives both before responding This time it adds 2,920 to its acknowledgement number and transmits 14,380, indicating that it received both segments Again, slow-start allows the sender to

increase the number of segments transmitted Now the server sends three segments to complete the delivery The client receives the first two and acknowledges those 2,920 bytes with the ack = 17,300 While the TCP standard does not require it, nearly all implementations acknowledge the second segment immediately Upon receiving the last segment, the client station delays slightly to determine whether it has any out-going data Having none, it acknowledges the last segment and the transmission is complete

TCP Performance

Traditionally, the efficiency of a data communications task is defined as the ratio of the data successfully transferred to the total number units (bits or bytes) transferred Before we introduce errors to the analysis,

we will consider the efficiency of the normal transfer illustrated in Figure 5:

Total data bytes transferred = 8,000 Total TCP bytes transferred (including six 20-byte headers and four 20-byte acks) = 8,200 bytes TCP throughput = (8000/8200) = 97.6 % Total Ethernet bytes transferred (TCP data + 58 bytes for segments sent; 64 bytes for acks)= 8,604 Ethernet efficiency = (8000/8604) = 92.9%

In other words, even if there are no errors during transmission, only about 93% of the transmitted information is actually the "sent" data

For this study, we have defined Ethernet efficiency to be the ratio of TCP data bytes transferred to total Ethernet bytes transferred This analysis of efficiency is based on the number of bytes transmitted If the basis of the analysis were changed to elapsed time we would get a different perspective We will make reference to this later and in the conclusion to the paper

Now consider a situation in which errors are introduced Let us examine several illustrations in which a single bit error occurs during the transfer we just analyzed In Figure 6, assume that a single erred bit has corrupted the third segment that is transmitted

even if there are

no errors during

[Ethernet]

trans-mission, only 93%

of the transmitted

information is the

“sent” data

The 200 ms delay is based on a widely used TCP technique called delayed acknowledgement Normally a receiver will not acknowledge a single segment immediately It will wait up to 200 ms to see it it's own application has any outgoing data The intent is to reduce the number of segments in transit in the network If there is outgoing data, it will "piggy-back"

its data on the packet that acts as the acknowledge-ment In the illustration in the figure above, there is no data to return from Station B So Station B's TCP will wait until the timer expires and send an

acknowledgement to the single segment it received that contained sequence number 11,460

If we repeat our performance analysis based on Figure

6, we have:

Total data bytes transferred = 8000 Total TCP bytes transferred (including additional retransmission of 1460 bytes, seven 20-byte headers and four 20-byte acks) = 9,680 bytes

TCP throughput = (8000/9680) = 82.6 % Total Ethernet bytes transferred (TCP data + 58 bytes for each of the segments sent; 64 bytes for each ack) = 10,122

Ethernet efficiency = (8000/10122) = 79.0%

Link BER for figure 6 = (1/ 80976)

or slightly over 10-5

By comparing the results of Figures 5 and 6 we can see that the single bit error reduces the efficiency of TCP over Ethernet by 15% (from 93% to 79%) Keep in mind that there will be additional time delay due to the 200 ms delay and the extra segments that are transmitted

Now lets consider another very similar situation This time we will assume that a different segment is corrupted and dropped This is shown in Figure 7:

Figure 7

In this instance the receiving client station knows immediately that a segment has arrived out of order

It deduces this because the sequence number in the second segment that it receives does not match the acknowledgement number it has just sent to the server Consequently, it immediately sends a duplicate acknowledgement, indicating that it is still expecting

to receive the segment with sequence number 11,460 The sending station does not automatically conclude that this duplicate acknowledgement indicates that a segment has been lost It draws conclusion only after it has received three such duplicates So in this case, it does not retransmit until its Retransmission Timer expires

the single bit

error reduces the

efficiency of TCP

over Ethenet by

15%

The timer is referred to by the acronym RTO for

retransmission timeout It is calculated for each outgoing

segment by a rather complex algorithm For our

purposes, it is sufficient to know that the RTO is

generally approximately twice the round-trip time For

example, if the average time for a packet to get from

Station A to Station B across an internet connection

would be 600 ms., the RTO for a segment sent by

Station A would likely be about 1.2 seconds After the

timer has expired, the sender retransmits segments

beginning with the last acknowledgement number it has

received It also does not increase the number of

segments transmitted in the block Hence, unlike the

last example, this time a single segment is sent instead of

two segments

Repeating the efficiency analysis we see that:

Total data bytes transferred = 8000

Total TCP bytes transferred (including additional

retransmission of 1460 bytes, seven 20-byte headers

and five 20-byte acks) = 9,700 bytes

TCP throughput = (8000/9700) = 82.4 %

Total Ethernet bytes transferred (TCP data + 58

bytes for each of the segments sent; 64 bytes for

each ack) = 10,186 bytes

Ethernet efficiency = (8000/10186) = 78.5%

Link BER = (1/81488) or slightly over 10-5

Next, we will introduce a second bit error In this case, a

bit is corrupted in a transmitted segment and a bit is

corrupted in an acknowledgement This is illustrated in

Figure 8

This time the first retransmission occurred for the same

reasons that it did in the previous example But when

the segment carrying the acknowledgement 18,000 is

dropped, two negative things happen First, the server

has its RTO expire, which adds delay Then, because of

this, it assumes there may be congestion and does not

increase the number of segments transmitted as a block

These two events combine to add two retransmitted

segments and one additional acknowledgement

Additionally there is a significant additional delay (in

time)

Figure 8

If we repeat the efficiency analysis, we find that: Total data bytes transferred = 8000

Total TCP bytes transferred (including additional retransmission of 3620 bytes, nine 20-byte headers and seven 20-byte acks) = 11,940 bytes

TCP throughput = (8000/11940) = 67.0%

Total Ethernet bytes transferred (seven 1518 byte frames, two 758 byte frames; seven 64 byte acks) = 12,590 bytes

Ethernet efficiency = (8000/12590) = 63.5% Link BER = (2/100720) or approximately 10-5

Several observations may be noted Again, we do not have time stamps associated with the example

However, it is obvious that we had additional round trips as well as additional RTO expiration The addi-tional time could be reasonably estimated at 20-40% of the original transfer time, or even more This would depend on whether this transfer occurred over a LAN link or over something like a sequence of Internet links

Also, the additional transmissions and acknowledgements are a result of the way in which TCP is designed TCP is used between clients and database servers on LANs; it is also used between web browser clients and web servers across multiple WAN links Since TCP is used over a wide variety of such links, the algorithms that are designed to provide good general performance may cause significant increases in specific instances such as those provided here

An Estimate of Delay Caused by Bit Errors

Using Figure 5 and Figure 8, let us make a few reasonable assumptions and determine whether we can estimate the amount of additional time delay has been introduced by the two bit errors First, assume that the one way transit time for a segment is 125 ms

That would make the round-trip time 250 ms, a typical result for a web-based client-server application Also, suppose that the sender can transmit a segment that is queued in its TCP output buffer within a few millisec-onds From Figure 5, we can estimate the time required for the file transfer:

250 ms (transmit/ack segment with sequence number 10,000)

+250 ms (transmit/ack segment with sequence number 12,920)

+250 ms (transmit/ack segments with sequence numbers 14,380 and 15,840) +200 ms ( delayed ack implied here but discussed with Figure 6)

Total elapsed time: 950 ms

If we do a similar analysis with Figure 8, we have:

250 ms (transmit/ack segment with sequence number 10,000)

+500 ms (RTO expiration) +250 ms (transmit/ack segment with sequence number 11,460)

+250 ms (transmit/ack segment with sequence number 14,380)

+500 ms (RTO expiration) +250 ms (transmit/ack segment with sequence number 15,840)

+250 ms (transmit/ack segment with sequence number 17,300)

Total elapsed time: 2,000 ms

By comparing the results, we can estimate that the time to complete the task more than doubles

To conclude this section on TCP performance, we have gathered and summarized the results of the examples in the following table:

From # Bit Approx TCP Efficiency TCP Efficiency Figure Errors BER over Ethernet

5 0 0 97.6% 93.0%

6 1 10-5 82.6% 79.0%

7 1 10-5 82.5% 78.5%

8 2 10-5 67.0% 63.5%

Conclusion

In this paper we investigated the relationship between errors that occur at the physical level of the network and TCP performance We did this by reviewing: (1) The structure of a TCP/IP transmitted data packet in an Ethernet environment,

(2) How errors at physical, data link and protocol levels are detected, and

(3) The operation of the TCP protocol

First we reviewed the meaning of the bit error rate Then, we established that it is distinct from the frame error rate In particul ar, if the bit error rate is a typical value such as 10-10, the frame error rate for

1250 byte Ethernet frames sent over the link will be approximately 10-6 That is, the frame error rate is approximately 10,000 times as high as the bit error rate Frame errors are usually detected by using the CRC algorithms We determined that CRC error checking operates at the level of the NIC (data link level) and is nearly infallible We also observed that when a checksum is used by a protocol it is not as robust as CRC but is usually a redundant check, designed to determine primarily whether information has been corrupted after it was received

Next we studied several examples of TCP transmis-sions When errors were introduced, we observed that the reduction in efficiency of both TCP and Ethernet was significant, even if the number of erred bits was very small In particular, the amount by which efficiency is degraded is dependent on where the

we can estimate

the time delay

introduced by two

bit errors the

time to complete

the task more than

doubles