With standardized confirm selection options, TCP SACK receiving end function may be provided by a TCP header to the received data which describe the cumulative ACK number field . Mentioned before, an interval called an ACK gap between the number and the other data receiving side cache. Sequence number higher than the vacancy data is called out of sequence data, since these data and previously received sequence number discontinuity
Benefits of using SACK
TCP sender task is by retransmitting lost data cache to fill vacancies in receiving end , but we must ensure as far as possible not to retransmit the data has been correctly received
In many environments, rational use of SACK information can be realized more quickly to fill the vacancy, and can reduce unnecessary retransmissions due to its internal RTT can learn in a multiple vacancies
Use the concepts of SACK
When the SACK option, an ACK may comprise three or four SACK information to inform the data out of order . Each SACK information includes 32-bit serial number, data representative of the receiving side out of order storing of the start to the last sequence number (plus 1)
Specifies the length of the n blocks SACK option is 8n + 2 bytes, and therefore may comprise up to four 40 byte blocks
SACK will typically use TSOPT together , thus requiring additional 10 bytes (plus two bytes of padding data), which means SACK in each ACK can contain only three blocks. 3 shows that the block can be three vacant report to the sender. If the congestion control without limitation, the use of SACK option to fill the three vacancies at a time RTT . Comprising one or more SACK blocks ACK is sometimes referred to simply as "SACK"
Two, SACK receiving side behavior
The receiving end in the SACK TCP connection is established to receive licensing options to generate SACK period. Generally speaking, whenever there is data in the cache out of order, the receiving side can generate SACK
Data disorder causes might be:
Since the loss during transport
It could be the first to reach the new data to the old data
Here only discuss the first case, the latter left for later discussion
SACK blocks of different content
In the above description we know a containing ACK SACK option, SACK can be divided into several blocks:
A first inner SACK block contains the serial number range segment of the most recently received. Due to limited space SACK option should ensure as far as possible to provide the latest information to the TCP sender
SACK blocks remaining contents are also included in the received successively arranged in order
That is, the latest contents of a block included in addition to containing the information most recently received sequence number, the SACK need to repeat the previous block (other packet segment)
SACK blocks comprising a plurality of object in one of the ACK
SACK blocks comprising a plurality of object in a SACK option, and the information is repeated a plurality of SACK blocks in that in order to prevent the loss of some backup SACK
If SACK not lose, [RFC2018] pointed out that each contains a SACK SACK block to achieve the full functionality of SACK. Unfortunately, the SACK ordinary ACK sometimes lost , and if it does not contain data (SYN FIN or not the control bit field is set) will not be retransmitted
Three, SACK the sender behavior
Although a SACK support receiving end can be generated by the full use of the SACK SACK appropriate information, but not enough to make full use of the SACK TCP connection function. At the transmitting end it should also provide SACK function, and rational use of the received SACK blocks to perform retransmission of lost , this process is also referred to as selective or selective retransmission of the retransmission
Works sender
Avoid retransmission correct data:
SACK transmitting side records the cumulative ACK information received (like most TCP sender the same), needed to record SACK received information , and use this information to avoid data retransmission of correctly received
A method for the ACK when receiving the corresponding serial number range, then the retransmission buffer in its tag selection of the segment retransmission success
When SACK transmitting end performs retransmission, usually due to duplicate the ACK or SACK received, it may choose to send new data or retransmission of old data. SACK information providing-side data received serial number range, and therefore the transmitting side may infer the missing data needs to be retransmitted . The easiest way is to fill the gap of the transmission side receiving end first, and then continue to send new data [RFC3517] (congestion control mechanism if allowed). This is the most commonly used method
A special case
The behavior with one exception. In [RFC2018] in, and SACK option SACK blocks in the current specification is advisory. This means that the receiving end may provide a SACK tell the sender has been successfully received data of a certain serial number range, and then make changes ( "renege"). For this reason, SACK transmission side can not be emptied immediately after it receives a SACK retransmission data cache ; only when the maximum value of the sequence number the receiving end ordinary TCP ACK number is larger than can be cleared
The rules also affect the behavior of the retransmission timer expires. When the TCP sender starts a timer-based retransmission of any data on the reception side SACK disorder displayed information should be ignored. If the receiver still out of order data, then the ACK packet retransmitted segment contains additional SACK blocks to use for transmission. Fortunately, his word is rarely the case, we should try to avoid
Fourth, the demo case
To understand how it affects SACK the sender and receiver behavior, we repeat the previous fast retransmit experiments, parameter settings are as before (losing serial numbers 23601 and 28801), but this time the sender and receiver are used SACK. To accurately observed during the experiment, we still use Wireshark TCP sequence number map functions (see below)
FIG previous upper "fast retransmit" article similar examples, but using SACK information, the transmitting end after completion of re-transmission segment 23601, and then having to wait for a retransmission of the lost RTT segment 28801. Will carefully discuss these later, now we first verify that allowed SACK (SACK-Permitted) option in the connection establishment process, see below
Like expected, the receiving terminal SACK allowed option to use SACK. SYN packet transmitting side, i.e. the first packet of the record, also includes the option. Daily News segment these options will only be able to see the connection establishment phase, so only in the SYN bit set
Once the connection is allowed to use SACK, i.e., packet loss will cause the receiving side starts to generate SACK. Wireshark displays the contents of the first SACK option (see below)
The following figure shows the first of a series of events after SACK is received. wireshark represented SACK SACK information about the boundary range. Here we see an ACK 23801 contains a SACK block [25201, 26601], indicating vacancy receiving end. Receiving terminal deletion range Serial No. [23801,25200], equivalent to a 1400-byte packet serial number 23801 from the beginning. Noting that the SACK is a window update, and can not qualify as a duplicate ACK, also mentioned before, it can not trigger the fast retransmit
