In many cases, even if there is no data loss occurs could lead to retransmission . Such unnecessary retransmissions called spurious retransmission , which is the main cause of the pseudo timeout, i.e. premature timeout is determined , other factors such as out of sequence packet, the packet is repeated, or may lead to the loss of ACK phenomenon . In the actual RTT significant increase over the current RTO, pseudo timeout may occur. Lower layer protocol performance in large changes in the environment (such as a wireless environment), this happens more than, [KP87] also mentioned
Here we focus only on spurious retransmission timeouts caused by the false . Effect disorder and repeated in the following sections discuss
It proposed a number of ways to deal with spurious timeout issue . These methods typically comprise the detection algorithm in response to algorithm . A detection algorithm for determining whether the timer timeout or retransmission based true, once identified spurious timeout response algorithm is performed, for revoking or mitigate the effects of the time-out. In this chapter we discuss only retransmit behavior segment. A typical response is also directed to a congestion control algorithm changes, will be "the TCP congestion control" described later
Icon (rollback "N" behavior)
The following figure depicts a simplified TCP exchange
8 on the segment transmitted after the completion of the link ACK delay occurs resulting in a peak spurious retransmissions . After 5 segment retransmission timeout, the original transmission segment 5 - ACK 8 is still in the pass state
For simplicity in this figure, the sequence number and ACK numbers are not based on packet bytes to represent, and ACK number indicates the received packet, rather than a desired reception packet. When the ACK arrives, the sender continues to retransmit the other segments already received, starting after the segment has been confirmed. This led to the emergence of TCP "Back N" patterns of behavior, and produce a more "duplicate ACK" return to the sender, then it may trigger the fast retransmit . To solve this problem, we suggest ways to mitigate adverse effects. Below we discuss one of the more commonly used in several ways
Second, repeated SACK (DSACK) extended
In the non-SACK TCP in, ACK can only inform the largest order segment to the sender. Using SACK can inform other (disorder) segment . SACK basic mechanism of how it works when the receiver receives duplicate data segment is not specified . These data may be repeated spurious retransmission, resulting in a network or for other reasons repeated
Sending end DSACK
In the receiving end DSACK SACK (or referred to DSACK), i.e., repeated SACK [RFC2883], SACK conventional transmission combined with an end, may inform the receiver receives a first SACK block sequence number repeating segments
DSACK's main purpose is to determine when the retransmission is unnecessary , and learn about other matters in the network. Thus the sending end may deduce whether at least the covered disorder, the ACK loss, packet retransmission is repeated or pseudo
DSACK compared to conventional SACK does not require additional negotiation process . To make it work, the SACK content returned by the receiver will change in response to the transmitting side corresponding also changed. If a non-TCP DSACK share a connection with DSACK, they interact, but can not use non-DSACK features DSACK
DSACK receiving end
SACK receiving end changes that allow the SACK blocks comprising the sequence number is less than (or equal to) the cumulative ACK number field . SACK this is not the intention, but this can be a good fit for this purpose. (In the case of information than the cumulative ACK DSACK number field, i.e. the duplicate packets out of order segments, it also works well) DSACK information is contained only in a single ACK, the ACK is referred DSACK
SACK information different from the usual, DSACK SACK information is not repeated in the plurality. Therefore, DSACK than usual robustness of SACK low
[RFC2883] does not specify how to deal with the sending end DSACK. [RFC3708] gives an experimental method, using DSACK spurious retransmission is detected, but it does not provide a response algorithm. It can be mentioned the Eifel Response algorithm, we discuss below, before we start with some other detection operators in France
Three, Eifel detection algorithm
concept:
In front, we discussed the retransmission ambiguity problem. Eifel detection algorithm experimental [RFC3522] use of TCP to detect the spurious retransmissions TSOPT
Retransmission occurs after a timeout, the Eifel a waiting to receive the ACK algorithm, if it is confirmed for the first transmission (i.e., the original) is transmitted , it is determined that the retransmission is spurious retransmissions
Compared with the DSACK:
Eifel Detection algorithm using the ratio of the detected earlier using only DSACK spurious retransmission behavior , because it determines the ACK spurious retransmission generated prior to starting the loss recovery
Instead, DSACK transmitted only after repeated segment arrives at the receiving end, and to be returned in response to the transmitting end after DSACK
Early detection of spurious retransmission more advantageously, it can effectively prevent the sending end of the aforementioned "fallback N" Behavior
Eifel detection algorithm principle
Mechanism Eifel detection algorithm is simple. It requires the use of TCP TSOPT
Sending end: When sending a retransmission (whether timer-based retransmission or fast retransmission) , and stores the value TSV
The receiving end: after receiving the corresponding ACK packet, the ACK is checked TSER portion . If the value is less than TSER TSV value previously stored , it can be determined that the ACK corresponding to the original packet transmission, i.e. the retransmission is spurious retransmissions
This approach needle of ACK loss also has good robustness . If an ACK is lost, TSER subsequent ACK value is still smaller than the retransmission packet TSV stored. Reach either ACK within this window can determine whether there is spurious retransmission, so a single ACK loss will not cause much of a problem
Eifel detection algorithm may be used in conjunction with DSACK, which can solve the ACK information for the entire window are lost , but the original transmission and the retransmission packet successfully reaching the receiving end. In this particular case, the retransmission packet arrival will generate a DSACK. Eifel algorithm rightly identified the emergence of spurious retransmissions. However, in the case where there has been so much at the ACK is lost, so that the retransmission is not believed TCP spurious retransmission is useful (e.g., so as to slow down the rate of transmission - using the consequences of congestion control). Thus, arriving DSACK will make the Eifel retransmission algorithm finds the corresponding spurious retransmissions are not
Fourth, migration RTO recovery algorithm (F-RTO)
Forward recovery RTO (Forward-RTO Recovery, F- RTO) [RFC5682] standard algorithm is detection of a spurious retransmission. It does not require any TCP options, so as long as the sender after the implementation of the method, even if that do not support the receiving end TSOPT can also work effectively. The algorithm detects only spurious retransmission by the retransmission timer timeout triggered; dummy retransmission of the previously mentioned other causes can not be determined due to
After a timer-based retransmission, F-RTO TCP common behavior will make some changes. Since this type of retransmission for the lowest sequence number is not received ACK information, under normal circumstances, TCP will continue to send sequentially adjacent packets, which is the previously described "Back N" behavior
working principle
F-RTO modify TCP behavior at the time of receipt of the first ACK after the retransmission timeout , TCP will transmit a new (non-retransmission) data, after then after arrival of a response ACK
If there is a duplicate ACK , the retransmission is considered to be no problem
If these are not duplicate ACK, it indicates that the retransmission is spurious retransmissions
Duplicate ACK packet is received by the receiver section of the disorder produced. This method is relatively straightforward. If the transmission of new data obtained the corresponding ACK, the receiving end makes the window forward. If the new data transmission results in duplicate ACK, the receiving end has at least one or more vacancies. In both cases, the reception of new data will not affect the overall transmission performance of data (assuming the receiving terminal has sufficient storage space)
Five, Eifel response algorithm
Once determined spurious retransmission, a set of standard operations will be initiated, i.e. Eifel Response Algorithm [RFC4015]. Since the separation of the Eifel detection algorithm in response to algorithm logic, it can be any of a method of detecting discussed our previous combination. In principle overtime retransmission and fast retransmit Eifel response algorithm can be used, but only for the retransmission timeout to do the relevant provisions
Although the Eifel Response algorithm may be used in combination with other detection algorithms, but as early as possible whether the distinction (e.g. Eifel detection algorithm or F-RTO) or later (e.g. DSACK) detected depending pseudo timeout. The former is called pseudo expires, checking ACK or implemented by the original transmission. The latter is called pseudo timeout later, based on the ACK by the (pseudo) initiate retransmission timeout returned determined
Response algorithm for only the first retransmission event. If time-out occurs again before the recovery phase is completed, the response will not be executed algorithm. After retransmission timer times out, it looks at the value srtt and rttvar, and as such recording new variable sett_prev and rttvar_prev:
At any time after the timer expires, you will specify these two variables, but only when it is determined spurious timeout will use them for setting new RTO. In the above formula, G represents TCP clock granularity. srtt_prev set srtt plus twice the size of the clock due to: srtt value is too small, there may be spurious timeout. If srtt slightly larger, it may not be out occurs. srtt 2G plus get srtt_prev, after use srtt_prev to set RTO
After completing srtt_prev and rttvar_prev storage, it is necessary to trigger some kind of detection algorithm. After running the test algorithm to obtain a particular value, referred to as pseudo recovery. If a timeout is detected once the dummy, the dummy will be set to resume SPUR_TO. If it is detected late pseudo timeout, then it is set to LATE_SPUILTO. Otherwise, the time-out is normal timeout, TCP continues normal response behavior
If the pseudo-recovery is SPUR_TO, TCP can be operated until the recovery phase is complete. By the next segment to be transmitted (referred to as of SND.NXT) modifying the sequence number of the latest message is not transmitted through the segments (referred SND.MAX). This can be after the first retransmission avoid unnecessary "fallback N" behavior. If it is detected late pseudo first time expires generated for the first retransmission ACK, the SND.NXT not changed. In both cases, we must re-set congestion control state. And upon receiving an ACK segment is sent after the retransmission timer times out, then the following will update the value srtt, rttvar and RTO of:
Here, m is a sample value of RTT, which is based on the ACK timeout after transmitting the first data received and calculated. The purpose of these updates is that the variables, the actual RTT value may change dramatically, the current estimate of RTT is not suitable for setting the RTO. If the actual path of a sudden increase in the RTT (e.g. due to handover a new radio base station), and the current srtt rttvar becomes too small, should be re-set. On the other hand, RTT increases may be only temporary, then reset the value srtt and rttvar not so wise, and because of their previous value may be more accurate
In the new larger sample RTT value, the above equation try to achieve a balance of the above two cases. RTT historical value (and historical changes in the RTT) before doing so effectively abandoned. It will only increase in value in response algorithm srtt and rttvar of. If the RTT is not increased, it remained unchanged estimated value, which essentially is to ignore the occurrence of a timeout situation. In both cases, RTO or updated in the normal way, and set a new time-out value for the retransmission timer
