It represents the consensus of the IETF community. Constantine, et al. All rights reserved. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Requirements Language TCP Equilibrium Scope and Goals Path MTU Measuring RTT Measuring BB Measuring TCP Throughput TCP Metrics Transfer Time Ratio TCP Efficiency Buffer Delay Buffer Delay Percentage Calculation Results Interpretation Security Considerations Denial-of-Service Attacks User Data Confidentiality Interference with Metrics Normative References Additionally, business-class customers seek to conduct repeatable TCP Throughput tests between locations.
Since these organizations rely on the networks of the providers, a common test methodology with predefined metrics would benefit both parties. Note that the primary focus of this methodology is managed business- class IP networks, e. End-users with "best effort" access could use this methodology, but this framework and its metrics are intended to be used in a predictable managed IP network. No end-to-end performance can be guaranteed when only the access portion is being provisioned to a specific bandwidth capacity.
The intent behind this document is to define a methodology for testing sustained TCP Layer performance. See Section 1. Throughout this document, "maximum achievable throughput" refers to the theoretical achievable throughput when TCP is in the Equilibrium state.
At both ends of the TCP connection and for each socket, there are default buffer sizes. There are also kernel-enforced maximum buffer sizes. These buffer sizes can be adjusted at both ends transmitting and receiving. Examples include "iperf" UDP mode and manual packet-layer test techniques where packet throughput, loss, and delay measurements are conducted. When available, standardized testing similar to [ RFC ], but adapted for use in operational networks, MAY be used.
Note: [ RFC ] was never meant to be used outside a lab environment. Sections 2 and 3 of this document provide a general overview of the proposed methodology. Section 4 defines the metrics, while Section 5 explains how to conduct the tests and interpret the results. Devices, Links, and Paths Constantine, et al. The Congestion Avoidance phase, during which TCP ramps up to establish the maximum achievable throughput.
It is important to note that retransmissions are a natural by-product of the TCP congestion avoidance algorithm as it seeks to achieve maximum throughput. Figure 1. TCP test programs such as "iperf", "ttcp", etc. Scope and Goals Before defining the goals, it is important to clearly define the areas that are out of scope.
The typical kinds of sequence number comparisons which the TCP must perform include: a Determining that an acknowledgment refers to some sequence number sent but not yet acknowledged. The following comparisons are needed to process the acknowledgments. NXT A segment on the retransmission queue is fully acknowledged if the sum of its sequence number and length is less or equal than the acknowledgment value in the incoming segment.
When data is received the following comparisons are needed: RCV. WND [Page 25] September Transmission Control Protocol Functional Specification The first part of this test checks to see if the beginning of the segment falls in the window, the second part of the test checks to see if the end of the segment falls in the window; if the segment passes either part of the test it contains data in the window.
Actually, it is a little more complicated than this. Due to zero windows and zero length segments, we have four cases for the acceptability of an incoming segment: Segment Receive Test Length Window 0 0 SEG. We have taken advantage of the numbering scheme to protect certain control information as well.
This is achieved by implicitly including some control flags in the sequence space so they can be retransmitted and acknowledged without confusion i. Control information is not physically carried in the segment data space. Consequently, we must adopt rules for implicitly assigning sequence numbers to control.
The SYN and FIN are the only controls requiring this protection, and these controls are used only at connection opening and closing. For sequence number purposes, the SYN is considered to occur before the first actual data octet of the segment in which it occurs, while the FIN is considered to occur after the last actual data octet in a segment in which it occurs. The segment length SEG. LEN includes both data and sequence space occupying controls.
A connection is defined by a pair of sockets. New instances of a connection will be referred to as incarnations of the connection. The problem that arises from this is -- "how does the TCP identify duplicate segments from previous incarnations of the connection? To avoid confusion we must prevent segments from one incarnation of a connection from being used while the same sequence numbers may still be present in the network from an earlier incarnation.
We want to assure this, even if a TCP crashes and loses all knowledge of the sequence numbers it has been using. When new connections are created, an initial sequence number ISN generator is employed which selects a new 32 bit ISN. The generator is bound to a possibly fictitious 32 bit clock whose low order bit is incremented roughly every 4 microseconds.
Thus, the ISN cycles approximately every 4. For each connection there is a send sequence number and a receive sequence number. The initial send sequence number ISS is chosen by the data sending TCP, and the initial receive sequence number IRS is learned during the connection establishing procedure. For a connection to be established or initialized, the two TCPs must synchronize on each other's initial sequence numbers. This is done in an exchange of connection establishing segments carrying a control bit called "SYN" for synchronize and the initial sequence numbers.
Hence, the solution requires a suitable mechanism for picking an initial sequence number and a slightly involved handshake to exchange the ISN's. The synchronization requires each side to send it's own initial sequence number and to receive a confirmation of it in acknowledgment from the other side. Each side must also receive the other side's initial sequence number and send a confirming acknowledgment.
A three way handshake is necessary because sequence numbers are not tied to a global clock in the network, and TCPs may have different mechanisms for picking the ISN's.
The receiver of the first SYN has no way of knowing whether the segment was an old delayed one or not, unless it remembers the last sequence number used on the connection which is not always possible , and so it must ask the sender to verify this SYN.
The three way handshake and the advantages of a clock-driven scheme are discussed in [ 3 ]. Knowing When to Keep Quiet To be sure that a TCP does not create a segment that carries a sequence number which may be duplicated by an old segment remaining in the network, the TCP must keep quiet for a maximum segment lifetime MSL before assigning any sequence numbers upon starting up or recovering from a crash in which memory of sequence numbers in use was lost.
For this specification the MSL is taken to be 2 minutes. This is an engineering choice, and may be changed if experience indicates it is desirable to do so. Note that if a TCP is reinitialized in some sense, yet retains its memory of sequence numbers in use, then it need not wait at all; it must only be sure to use sequence numbers larger than those recently used. The TCP Quiet Time Concept This specification provides that hosts which "crash" without retaining any knowledge of the last sequence numbers transmitted on each active i.
In the paragraphs below, an explanation for this specification is given. TCP implementors may violate the "quiet time" restriction, but only at the risk of causing some old data to be accepted as new or new data rejected as old duplicated by some receivers in the internet system. TCPs consume sequence number space each time a segment is formed and entered into the network output queue at a source host. Without such an assumption, two distinct TCP segments could conceivably be [Page 28] September Transmission Control Protocol Functional Specification assigned the same or overlapping sequence numbers, causing confusion at the receiver as to which data is new and which is old.
Remember that each segment is bound to as many consecutive sequence numbers as there are octets of data in the segment. Under normal conditions, TCPs keep track of the next sequence number to emit and the oldest awaiting acknowledgment so as to avoid mistakenly using a sequence number over before its first use has been acknowledged. This alone does not guarantee that old duplicate data is drained from the net, so the sequence space has been made very large to reduce the probability that a wandering duplicate will cause trouble upon arrival.
The basic duplicate detection and sequencing algorithm in TCP can be defeated, however, if a source TCP does not have any memory of the sequence numbers it last used on a given connection.
For example, if the TCP were to start all connections with sequence number 0, then upon crashing and restarting, a TCP might re-form an earlier connection possibly after half-open connection resolution and emit packets with sequence numbers identical to or overlapping with packets still in the network which were emitted on an earlier incarnation of the same connection. In the absence of knowledge about the sequence numbers used on a particular connection, the TCP specification recommends that the source delay for MSL seconds before emitting segments on the connection, to allow time for segments from the earlier connection incarnation to drain from the system.
Even hosts which can remember the time of day and used it to select initial sequence number values are not immune from this problem i. Suppose, for example, that a connection is opened starting with sequence number S.
Suppose that this connection is not used much and that eventually the initial sequence number function ISN t takes on a value equal to the sequence number, say S1, of the last segment sent by this TCP on a particular connection.
Now suppose, at this instant, the host crashes, recovers, and establishes a new incarnation of the connection. If the recovery occurs quickly enough, any old [Page 29] September Transmission Control Protocol Functional Specification duplicates in the net bearing sequence numbers in the neighborhood of S1 may arrive and be treated as new packets by the receiver of the new incarnation of the connection.
The problem is that the recovering host may not know for how long it crashed nor does it know whether there are still old duplicates in the system from earlier connection incarnations.
One way to deal with this problem is to deliberately delay emitting segments for one MSL after recovery from a crash- this is the "quite time" specification. Hosts which prefer to avoid waiting are willing to risk possible confusion of old and new packets at a given destination may choose not to wait for the "quite time". Implementors may provide TCP users with the ability to select on a connection by connection basis whether to wait after a crash, or may informally implement the "quite time" for all connections.
Obviously, even where a user selects to "wait," this is not necessary after the host has been "up" for at least MSL seconds. To summarize: every segment emitted occupies one or more sequence numbers in the sequence space, the numbers occupied by a segment are "busy" or "in use" until MSL seconds have passed, upon crashing a block of space-time is occupied by the octets of the last emitted segment, if a new connection is started too soon and uses any of the sequence numbers in the space-time footprint of the last segment of the previous connection incarnation, there is a potential sequence number overlap area which could cause confusion at the receiver.
Establishing a connection The "three-way handshake" is the procedure used to establish a connection. The procedure also works if two TCP simultaneously initiate the procedure.
Of course, the arrival of an old duplicate "SYN" segment can potentially make it appear, to the recipient, that a simultaneous connection initiation is in progress. Proper use of "reset" segments can disambiguate these cases. Several examples of connection initiation follow. Although these examples do not show connection synchronization using data-carrying segments, this is perfectly legitimate, so long as the receiving TCP doesn't deliver the data to the user until it is clear the data is valid i.
The three-way handshake reduces the possibility of false connections. It is the [Page 30] September Transmission Control Protocol Functional Specification implementation of a trade-off between memory and messages to provide information for this checking.
The simplest three-way handshake is shown in figure 7 below. The figures should be interpreted in the following way. Each line is numbered for reference purposes. An "XXX" indicates a segment which is lost or rejected. Comments appear in parentheses. Segment contents are shown in abbreviated form, with sequence number, control flags, and ACK field.
Other fields such as window, addresses, lengths, and text have been left out in the interest of clarity. In line 2 of figure 7, TCP A begins by sending a SYN segment indicating that it will use sequence numbers starting with sequence number Note that the acknowledgment field indicates TCP B is now expecting to hear sequence , acknowledging the SYN which occupied sequence Note that the sequence number of the segment in line 5 is the same as in line 4 because the ACK does not occupy sequence number space if it did, we would wind up ACKing ACK's!
The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion. To deal with this, a special control message, reset, has been devised.
If the receiving TCP is in a non-synchronized state i. We discuss this latter case under "half-open" connections below. As a simple example of recovery from old duplicates, consider figure 9.
TCP B cannot tell that this is an old duplicate, so it responds normally line 4. When the original SYN pun intended finally arrives at line 6, the synchronization proceeds normally. Half-Open Connections and Other Anomalies An established connection is said to be "half-open" if one of the TCPs has closed or aborted the connection at its end without the knowledge of the other, or if the two ends of the connection have become desynchronized owing to a crash that resulted in loss of memory.
Such connections will automatically become reset if an attempt is made to send data in either direction. However, half-open connections are expected to be unusual, and the recovery procedure is mildly involved. If at site A the connection no longer exists, then an attempt by the [Page 33] September Transmission Control Protocol Functional Specification user at site B to send any data on it will result in the site B TCP receiving a reset control message.
Such a message indicates to the site B TCP that something is wrong, and it is expected to abort the connection. Assume that two user processes A and B are communicating with one another when a crash occurs causing loss of memory to A's TCP.
Depending on the operating system supporting A's TCP, it is likely that some error recovery mechanism exists. When the TCP is up again, A is likely to start again from the beginning or from a recovery point.
In the latter case, it receives the error message "connection not open" from the local A's TCP. This scenario leads to the example shown in figure After TCP A crashes, the user attempts to re-open the connection. TCP B, in the meantime, thinks the connection is open. CRASH send ,receive 2.
When the SYN arrives at line 3, TCP B, being in a synchronized state, and the incoming segment outside the window, responds with an acknowledgment indicating what sequence it next expects to hear ACK TCP A sees that this segment does not acknowledge anything it sent and, being unsynchronized, sends a reset RST because it has detected a half-open connection.
TCP B aborts at line 5. TCP A will [Page 34] September Transmission Control Protocol Functional Specification continue to try to establish the connection; the problem is now reduced to the basic 3-way handshake of figure 7. This is illustrated in figure Reset Generation As a general rule, reset RST must be sent whenever a segment arrives which apparently is not intended for the current connection.
A reset must not be sent if it is not clear that this is the case. There are three groups of states: 1. If the connection does not exist CLOSED then a reset is sent in response to any incoming segment except another reset.
In particular, SYNs addressed to a non-existent connection are rejected by this means. If the incoming segment has an ACK field, the reset takes its sequence number from the ACK field of the segment, otherwise the reset has sequence number zero and the ACK field is set to the sum of the sequence number and segment length of the incoming segment. If our SYN has not been acknowledged and the precedence level of the incoming segment is higher than the precedence level requested then either raise the local precedence level if allowed by the user and the system or send a reset; or if the precedence level of the incoming segment is lower than the precedence level requested then continue as if the precedence matched exactly if the remote TCP cannot raise the precedence level to match ours this will be detected in the next segment it sends, and the connection will be terminated then.
If our SYN has been acknowledged perhaps in this incoming segment the precedence level of the incoming segment must match the local precedence level exactly, if it does not a reset must be sent.
The connection remains in the same state. If an incoming segment has a security level, or compartment, or precedence which does not exactly match the level, and compartment, and precedence requested for the connection,a reset is sent and connection goes to the CLOSED state. The reset takes its sequence number from the ACK field of the incoming segment. A reset is valid if its sequence number is in the window. The receiver of a RST first validates it, then changes state.
Users must keep reading connections they close for sending until the TCP says no more data. All segments preceding and including FIN will be retransmitted until acknowledged. If an ACK is not forthcoming, after the user timeout the connection is aborted and the user is told. Both will, upon receiving these ACKs, delete the connection.
Precedence and Security The intent is that connection be allowed only between ports operating with exactly the same security and compartment values and at the higher of the precedence level requested by the two ports.
Rejecting a connection due to too low a precedence only occurs after an acknowledgment of the SYN has been received. Note that TCP modules which operate only at the default value of precedence will still have to check the precedence of incoming segments and possibly raise the precedence level they use on the connection.
The security paramaters may be used even in a non-secure environment the values would indicate unclassified data , thus hosts in non-secure environments must be prepared to receive the security parameters, though they need not send them.
Data Communication Once the connection is established data is communicated by the exchange of segments. Because segments may be lost due to errors checksum test failure , or network congestion, TCP uses retransmission after a timeout to ensure delivery of every segment.
Duplicate segments may arrive due to network or TCP retransmission. As discussed in the section on sequence numbers the TCP performs certain tests on the sequence and acknowledgment numbers in the segments to verify their acceptability. The sender of data keeps track of the next sequence number to use in the variable SND. The receiver of data keeps track of the next sequence number to expect in the variable RCV. The sender of data keeps track of the oldest unacknowledged sequence number in the variable SND.
If the data flow is momentarily idle and all data sent has been acknowledged then the three variables will be equal. When the sender creates a segment and transmits it the sender advances SND. When the receiver accepts a segment it advances RCV. NXT and sends an acknowledgment.
The extent to which the values of these variables differ is a measure of the delay in the communication. The amount by which the variables are advanced is the length of the data in the segment. Retransmission Timeout Because of the variability of the networks that compose an internetwork system and the wide range of uses of TCP connections the retransmission timeout must be dynamically determined.
One procedure for determining a retransmission time out is given here as an illustration. An Example Retransmission Timeout Procedure Measure the elapsed time between sending a data octet with a particular sequence number and receiving an acknowledgment that covers that sequence number segments sent do not have to match segments received.
The Communication of Urgent Information The objective of the TCP urgent mechanism is to allow the sending user to stimulate the receiving user to accept some urgent data and to permit the receiving TCP to indicate to the receiving user when all the currently known urgent data has been received by the user.
This mechanism permits a point in the data stream to be designated as the end of urgent information. Whenever this point is in advance of the receive sequence number RCV. If the urgent pointer is updated while the user is in "urgent mode", the update will be invisible to the user. The method employs a urgent field which is carried in all segments transmitted. The URG control flag indicates that the urgent field is meaningful and must be added to the segment sequence number to yield the urgent pointer.
The absence of this flag indicates that there is no urgent data outstanding. To send an urgent indication the user must also send at least one data octet. If the sending user also indicates a push, timely delivery of the urgent information to the destination process is enhanced. Managing the Window The window sent in each segment indicates the range of sequence numbers the sender of the window the data receiver is currently prepared to accept.
There is an assumption that this is related to the currently available data buffer space available for this connection.
Indicating a large window encourages transmissions. If more data arrives than can be accepted, it will be discarded. This will result in excessive retransmissions, adding unnecessarily to the load on the network and the TCPs.
Indicating a small window may restrict the transmission of data to the point of introducing a round trip delay between each new segment transmitted. The mechanisms provided allow a TCP to advertise a large window and to subsequently advertise a much smaller window without having accepted that much data.
This, so called "shrinking the window," is strongly discouraged. The robustness principle dictates that TCPs will not shrink the window themselves, but will be prepared for such behavior on the part of other TCPs.
The sending TCP must be prepared to accept from the user and send at least one octet of new data even if the send window is zero. Two minutes is recommended for the retransmission interval when the window is zero.
This retransmission is essential to guarantee that when either TCP has a zero window the re-opening of the window will be reliably reported to the other. When the receiving TCP has a zero window and a segment arrives it must still send an acknowledgment showing its next expected sequence number and current window zero. The sending TCP packages the data to be transmitted into segments [Page 42] September Transmission Control Protocol Functional Specification which fit the current window, and may repackage segments on the retransmission queue.
Such repackaging is not required, but may be helpful. In a connection with a one-way data flow, the window information will be carried in acknowledgment segments that all have the same sequence number so there will be no way to reorder them if they arrive out of order. This is not a serious problem, but it will allow the window information to be on occasion temporarily based on old reports from the data receiver.
A refinement to avoid this problem is to act on the window information from segments that carry the highest acknowledgment number that is segments with acknowledgment number equal or greater than the highest previously received.
The window management procedure has significant influence on the communication performance. The following comments are suggestions to implementers. Window Management Suggestions Allocating a very small window causes data to be transmitted in many small segments when better performance is achieved using fewer large segments.
One suggestion for avoiding small windows is for the receiver to defer updating a window until the additional allocation is at least X percent of the maximum allocation possible for the connection where X might be 20 to Another suggestion is for the sender to avoid sending small segments by waiting until the window is large enough before sending data. If the the user signals a push function then the data must be sent even if it is a small segment.
Note that the acknowledgments should not be delayed or unnecessary retransmissions will result. One strategy would be to send an acknowledgment when a small segment arrives with out updating the window information , and then to send another acknowledgment with new window information when the window is larger.
The segment sent to probe a zero window may also begin a break up of transmitted data into smaller and smaller segments. If a segment containing a single data octet sent to probe a zero window is accepted, it consumes one octet of the window now available. If the sending TCP simply sends as much as it can whenever the window is non zero, the transmitted data will be broken into alternating big and small segments. As time goes on, occasional pauses in the receiver making window allocation available will [Page 43] September Transmission Control Protocol Functional Specification result in breaking the big segments into a small and not quite so big pair.
And after a while the data transmission will be in mostly small segments. The suggestion here is that the TCP implementations need to actively attempt to combine small window allocations into larger windows, since the mechanisms for managing the window tend to lead to many small windows in the simplest minded implementations. Consequently, we must warn readers that different TCP implementations may have different user interfaces.
However, all TCPs must provide a certain minimum set of services to guarantee that all TCP implementations can support the same protocol hierarchy. This section specifies the functional interfaces required of all TCP implementations.
The notation used is similar to most procedure or function calls in high level languages, but this usage is not meant to rule out trap type service calls e. The user commands described below specify the basic functions the TCP must perform to support interprocess communication. Individual implementations must define their own exact format, and may provide combinations or subsets of the basic functions in single calls.
The latter consists of: a general information about a connection e. Depending upon the implementation of the TCP, the local network and TCP identifiers for the source address will either be supplied by the TCP or the lower level protocol e. These considerations are the result of concern about security, to the extent that no TCP be able to masquerade as another one, and so on.
Similarly, no process can masquerade as another without the collusion of the TCP. A passive open may have either a fully specified foreign socket to wait for a particular connection or an unspecified foreign socket to wait for any call. A fully specified passive call can be made active by the subsequent execution of a SEND. The timeout, if present, permits the caller to set up a timeout for all data submitted to TCP.
If data is not successfully delivered to the destination within the timeout period, the TCP will abort the connection. The present global default is five minutes. The precedence for the connection is the higher of the values requested in the OPEN call and received from the incoming request, and fixed at that value for the life of the connection.
Implementers may want to give the user control of this precedence negotiation. For example, the user might be allowed to specify that the precedence must be exactly matched, or that any attempt to raise the precedence be confirmed by the user. The minimum of cwnd and rwnd governs data transmission. Another state variable, the slow start threshold ssthresh , is used to determine whether the slow start or congestion avoidance algorithm is used to control data transmission, as discussed below.
Standards Track [Page 4] RFC TCP Congestion Control September Beginning transmission into a network with unknown conditions requires TCP to slowly probe the network to determine the available capacity, in order to avoid congesting the network with an inappropriately large burst of data.
The slow start algorithm is used for this purpose at the beginning of a transfer, or after repairing loss detected by the retransmission timer.
Slow start additionally serves to start the "ACK clock" used by the TCP sender to release data into the network in the slow start, congestion avoidance, and loss recovery algorithms. Setting ssthresh as high as possible allows the network conditions, rather than some arbitrary host limit, to dictate the sending rate. In cases where the end systems have a solid understanding of the network path, more carefully setting the initial ssthresh value may have merit e.
When cwnd and ssthresh are equal, the sender may use either slow start or congestion avoidance. Slow start ends when cwnd exceeds ssthresh or, optionally, when it reaches it, as noted above or when congestion is observed. During congestion avoidance, cwnd is incremented by roughly 1 full- sized segment per round-trip time RTT.
Congestion avoidance continues until congestion is detected. A drawback of this implementation is that it requires maintaining an additional state variable. When the number of bytes acknowledged reaches cwnd, then cwnd can be incremented by up to SMSS bytes. Equation 3 provides an acceptable approximation to the underlying principle of increasing cwnd by 1 full-sized segment per RTT. Note that for a connection in which the receiver is acknowledging every-other packet, 3 is less aggressive than allowed -- roughly increasing cwnd every second RTT.
Implementation Note: Older implementations have an additional additive constant on the right-hand side of equation 3.
This is incorrect and can actually lead to diminished performance [ RFC ]. Implementation Note: Some implementations maintain cwnd in units of bytes, while others in units of full-sized segments. The latter will find equation 3 difficult to use, and may prefer to use the counting approach discussed in the previous paragraph. On the other hand, when a TCP sender detects segment loss using the retransmission timer and the given segment has already been retransmitted by way of the retransmission timer at least once, the value of ssthresh is held constant.
Therefore, after retransmitting the dropped segment the TCP sender uses the slow start algorithm to increase the window from 1 full-sized segment to the new value of ssthresh, at which point congestion avoidance again takes over. As shown in [ FF96 ] and [ RFC ], slow-start-based loss recovery after a timeout can cause spurious retransmissions that trigger duplicate acknowledgments.
This document does not specify how to treat such acknowledgments, but does note this as an area that may benefit from additional attention, experimentation and specification. The purpose of this ACK is to inform the sender that a segment was received out-of-order and which sequence number is expected.
From the sender's perspective, duplicate ACKs can be caused by a number of network problems. First, they can be caused by dropped segments.
In this case, all segments after the dropped segment will trigger duplicate ACKs until the loss is repaired. Second, duplicate ACKs can be caused by the re-ordering of data segments by the network not a rare event along some network paths [ Pax97 ]. This will generate more timely information for a sender recovering from a loss through a retransmission timeout, a fast retransmit, or an advanced loss recovery algorithm, as outlined in section 4.
UNA as an indication that a segment has been lost. After receiving 3 duplicate ACKs, TCP performs a retransmission of what appears to be the missing segment, without waiting for the retransmission timer to expire.
The reason for not performing slow start is that the receipt of the duplicate ACKs not only indicates that a segment has been lost, but also that segments are most likely leaving the network although a massive segment duplication by the network can invalidate this conclusion. In other words, since the receiver can only generate a duplicate ACK when a segment has arrived, that segment has left the network and is in the receiver's buffer, so we know it is no longer consuming network resources.
Furthermore, since the ACK "clock" [ Jac88 ] is preserved, the TCP sender can continue to transmit new segments although transmission must continue using a reduced cwnd, since loss is an indication of congestion. The fast retransmit and fast recovery algorithms are implemented together as follows.
The lost segment starting at SND. This artificially "inflates" the congestion window by the number of segments three that have left the network and which the receiver has buffered. This artificially inflates the congestion window in order to reflect the additional segment that has left the network. Note: [ SCWA99 ] discusses a receiver-based attack whereby many bogus duplicate ACKs are sent to the data sender in order to artificially inflate cwnd and cause a higher than appropriate Allman, et al.
A TCP MAY therefore limit the number of times cwnd is artificially inflated during loss recovery to the number of outstanding segments or, an approximation thereof. Note: When an advanced loss recovery mechanism such as outlined in section 4.
NXT are assumed to have left the network but are still reflected in FlightSize. This is termed "deflating" the window. This ACK should be the acknowledgment elicited by the retransmission from step 3, one RTT after the retransmission though it may arrive sooner in the presence of significant out- of-order delivery of data segments at the receiver.
0コメント