The Effect of Errors on TCP Application Performance W H A T C A N ERRORS in Ethernet LANs to concepts because they are the most difficult that will be application performance? covered We will conclude the paper with a summary and some observations about how to control errors in your network This question has arisen time and time again since the KRONE® TrueNetTM structured cabling system was launched Background Information The simple answer is that errors can degrade application performance; the complicated 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 Messages sent from application to application in packet data networks such as LANs and WANs are encapsulated For example, as a server responds to a client provide his evaluation of what Ethernet errors would request, the message flows down through what is referred to as the protocol stack This is illustrated in Figure In most implementations, each of the layers shown creates one of the headers in the encapsulated to application performance The following paper presents message paper KRONE enlisted the help of an independent consultant, Dr Phil Hippensteel, to study this topic and Dr Hippensteels findings Figure 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 transaction-oriented systems and virtually all webenabled 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 communicate Then, well review the three classes of errors and how they are detected Once this background has been 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) 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: introduced, well study how TCP operates in some detail Some case studies will be used to illustrate these KRONE: 800-775-KRONE No part of this document may be reproduced without permission www.kroneamericas.com www.truenet-system.com ©2001 KRONE, Inc 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 The most widely used connection oriented protocol is TCP Next, lets focus on the two types of protocols Connectionoriented 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 implemented by a connectionoriented 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 communications 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 connection-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 KRONE: 800-775-KRONE No part of this document may be reproduced without permission 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, well 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)= 10.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 www.kroneamericas.com www.truenet-system.com ©2001 KRONE, Inc 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 illustrates how it works: 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 Figure 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: .as a matter of practice, think of CRC-32 as practically infallible 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 dependent 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 KRONE: 800-775-KRONE No part of this document may be reproduced without permission Character Character Character Character Character Character Character Character 1 0 0 0 0 0 0 0 0 0 1 0 1 1 Character 0 0 0 bits 1 1 1 0 0 1 1 1 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 not need to be concerned with the details of the 1s-complement sum process here By appending the BCC to the block, we will www.kroneamericas.com www.truenet-system.com ©2001 KRONE, Inc 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 Character Character Character Character Character Character Character BCC 1 0 0 0 0 0 0 0 0 1 1 0 1 1 0 0 0 1 1 1 0 0 0 0 1 1 1 When the receiver gets the message block, it will perform a similar calculation While this technique isnt 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 doesnt 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 environment? 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 connectionoriented 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 connection-oriented protocols to provide the reliability that they cannot System designers assume that if a protocol is connectionless, a connectionoriented 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 performance, well 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, lets 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 receivers 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 Well 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: Recall our conclusion from near the beginning of the paper: connectionless-oriented protocols depend on KRONE: 800-775-KRONE No part of this document may be reproduced without permission www.kroneamericas.com www.truenet-system.com ©2001 KRONE, Inc Figure 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 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 transmitting 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 KRONE: 800-775-KRONE No part of this document may be reproduced without permission 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 shows how this is often illustrated: Figure 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 information such as Ethernet The field labeled Head Length in Figure 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 (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, www.kroneamericas.com www.truenet-system.com ©2001 KRONE, Inc 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 turnedon. 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 stations 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 + KRONE: 800-775-KRONE No part of this document may be reproduced without permission · 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 Bs 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 doesnt agree to the requested size, it simply doesnt 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 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 www.kroneamericas.com www.truenet-system.com ©2001 KRONE, Inc · The ISN for the server is 10,000 · The senders buffer window size is initially 8k · Station As application has a total of 8,000 bytes to transmit · The session has already been established with a three-way handshake Figure .even if there are no errors during [Ethernet] transmission, only 93% of the transmitted information is the sent data 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% The server transmits a single segment of 1,460 bytes It does this due to a widely endorsed strategy called slowstart This algorithm is used because the sender doesnt 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 KRONE: 800-775-KRONE No part of this document may be reproduced without permission 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 www.kroneamericas.com www.truenet-system.com ©2001 KRONE, Inc Figure Link BER for figure = (1/ 80976) or slightly over 10-5 By comparing the results of Figures and 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: .the single bit error reduces the efficiency of TCP over Ethenet by 15% Figure 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 acknowledgement 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% KRONE: 800-775-KRONE No part of this document may be reproduced without permission 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 www.kroneamericas.com www.truenet-system.com ©2001 KRONE, Inc 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 Figure 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 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) 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 KRONE: 800-775-KRONE No part of this document may be reproduced without permission www.kroneamericas.com www.truenet-system.com ©2001 KRONE, Inc we can estimate the time delay introduced by two bit errors the time to complete the task more than doubles Several observations may be noted Again, we 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 additional 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 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 Figure Errors Approx BER 10-5 10-5 10-5 TCP Efficiency TCP Efficiency over Ethernet 97.6% 93.0% 82.6% 79.0% 82.5% 78.5% 67.0% 63.5% Conclusion An Estimate of Delay Caused by Bit Errors Using Figure 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 milliseconds 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 a similar analysis with Figure 8, we have: 250 ms (transmit/ack segment sequence number 10,000) +500 ms (RTO expiration) +250 ms (transmit/ack segment sequence number 11,460) +250 ms (transmit/ack segment sequence number 14,380) +500 ms (RTO expiration) +250 ms (transmit/ack segment sequence number 15,840) +250 ms (transmit/ack segment sequence number 17,300) Total elapsed time: 2,000 ms KRONE: 800-775-KRONE No part of this document may be reproduced without permission with with with with with 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 particular, 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 transmissions 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 www.kroneamericas.com www.truenet-system.com ©2001 KRONE, Inc error occurs: a single bit error can reduce efficiency by approximately one-fifth; two bit errors can reduce efficiency to approximately thee-fifths errors which occur at the physical level of the network significantly degrade the performance of TCP While we did not have time stamps associated with the TCP segments that were transferred, we were able to estimate the additional delay caused by bit errors Our estimates indicated that such delays are substantial This issue, which is the subject of a future paper, is significant For while an IT manager may be able to purchase more bandwidth to solve a problem of inefficiency in an application, the manager is not able to purchase additional time to solve the delay problem In the TCP/IP environment, we learned that Ethernet and IP operate in a connectionless manner On the other hand TCP is connection-oriented Consequently, when TCP based applications are being used, errors which occur at the physical level of the network, significantly degrade the performance of TCP This degradation is directly apparent in the performance of the application which is dependent upon TCP to provide the transport platform for delivery of its data Physical level errors will cause the application to wait for TCP to retransmit data and acknowledgements and the time period for completion of the task will be extended Note from the Editor: The concepts explored in this paper are put to practical use in two other white papers published by KRONE: Catching Up With TrueNet and Network Troubleshooting Using TrueNet Test Methodologies In Catching Up With TrueNet, experiments performed on actual cabling channels show the significant differences in error performance between what appears to be identical Category 5e cabling systems The throughput test bed methodology is explained, including a discussion of the errors made by others who have attempted to perfom throughput testing on cabling channels The paper concludes with an comparison of the error performance of the tested channels using the techniques discussed in this paper In Network Troubleshooting Using TrueNet Test Methodologies, a discussion of the TrueNet testing methdolodies is presented, including a discussion of the real value of post-installation active testing Screen shots from poorly performing networks at actual endusers across the country are also presented as real-world case studies in network performance problems KRONE: 800-775-KRONE No part of this document may be reproduced without permission www.kroneamericas.com www.truenet-system.com ©2001 KRONE, Inc Appendix: Bit Error Probability To determine the relationship between bit error rate (BER) and block error rate, we will assume that BER = p Then 1-p = the probability that the bit arrives without an error Since it is reasonable to assume independence between the transmission of successive bits, if two bits are transmitted the probability they arrive without being corrupted = (1-p)2 Likewise, the probability that three successive bits would arrive without errors is (1-p)3 We can generalize that the probability that n bits are transmitted and arrive successfully is (1-p)n Consequently: The probability that n successive bits are transmitted and at least one bit is corrupted = 1-(1-p)n = 1-[1-np+(n(n-1)/2)p2- ±pn] This is very nearly 1-(1-np)= np This results from the fact that we may assume that p is very small and only the second term in the binomial expansion is significant To illustrate how this result is useful, suppose we transmit 10,000 bits (say a 1250-byte Ethernet frame.) If the BER is 10-10, the probability the frame is corrupted is approximately: np = 104*10-10 = 10-6 This is about one chance in 100,000 This represents the approximate FCS error rate About the Author Dr Phil Hippensteel is a consultant and instructor from Harrisburg, Pennsylvania He is widely recognized for his knowledge of network infrastructure His clients include schools, government agencies, hospitals, manufacturing firms and universities He as worked with IBM, Sprint, Bethlehem Steel, KRONE, Fluke, Tyco Electronics, Mitel, and many other firms throughout the United States and Canada He has helped develop networking products and the training associated with those products After spending a substantial portion of his career in higher education as a professor and college administrator, Dr Hippensteel began teaching data communications and consulting He has been an instructure for several major universities and dozens of colleges He also regularly provides presentations at major conferences and seminars including Supercomm, Networld+Interop, and the meetings of the International Communications Associations Recently, he was the keynote speaker for a seminar series organized nationwide by Network World magazine KRONE, Inc North American Headquarters 6950 South Tucson Way Englewood, CO 80112-3922 Telephone: (303) 790.2619 Toll-Free: (800) 775.KRONE Facsimile: (303) 790.2117 info.usa@kroneamericas.com www.kroneamericas.com www.truenet-system.com KRONE: 800-775-KRONE No part of this document may be reproduced without permission www.kroneamericas.com www.truenet-system.com ©2001 KRONE, Inc ... www.truenet-system.com ©2001 KRONE, Inc Figure 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... 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... session to the other TCP entity The FIN bit is set to the value one or turnedon. The window size, sometimes just called the window, is the number of bytes the sending station has in its buffer