TCP's handling of sack and the processing details of the chaotic sequence

Source: Internet
Author: User
Tags ack rfc

Not easy Ah, the weather is very hot, finally to the weekend but nowhere to go, last night on the special application to the wife for a short weekend time to summarize the recent work, it is not easy, if the application is not approved, I have to use the night,
Because I almost do not have to sleep, can eat can not eat people, as long as there is water, shochu, just fine ... In the early morning, the heat woke up, it seems that I did not use the time to apply.
... This is 4:30 A.M. ...


RFC2018 describes the specification of TCP sack, which mainly regulates the definition of sack and the behavior recommendations of the sender and receiver at the time of using the feature. The RFC document itself is very easy to read, it is recommended to read it over and over, and I have to write this article for the sake of archiving, and also to describe the sack in a way that I think is easier to understand. Before writing, give a diagram that will always be used in this article to describe the interval in which the sending queue is divided into a TCP connection that supports sack, when an ACK arrives:





1. Processing of sack on the data transmitting side

To simply and quickly describe the processing of the sack, we first define a bunch of variables, as follows:


Prior una: last una

Una: this time una "prior una and una may be equal"

S[I]:SKB inside the sack option inside each of the sack segments

P[J]: Each packet in the transmission queue

Dsack: Record whether there are dsack in this sack section

Undo: Record Undoable counter, each retransmission of a packet will increment by 1, each time a packet dsack will be decremented by 1, if the 0 explanation can undo, the hair is gray.

Reord: Record the current detected disorder

Sack_out: The number of packets that are sack

Retrans_out: Number of packets that have been re-transmitted

Lost_out: The number of packets that have been lost


Then I give a simple data sending end processing sack algorithm, recorded as algorithm A:


"Phase 1: Determine if Dsack is included"
If S[0]. Left < UNA
Dsack=1"Description is the first case of Dsack,dsack"
else if s[0] by s[1] contains
Dsack=1"Description is the second case of Dsack,dsack"
Else
Dsack=0
endif


"Phase 2: Scan packet tcp option for all sack segments"
"Stage 2-1: Prelude!" The interval 0 is processed first (as shown in the opening diagram) and there is no packet "

If S[0]. Right < prior UNA
Undo=undo-1;
endif


"phase 2-2: Subject"
I=0
For each s[i]; Do
J=0
Fack=0
"Phase 2-1-1: Traverse packets in each transmission queue for each s[i] block"
For each p[j]; Do
Fack=fack+1"Record the location of the current P[j]"
If P[J] s[i] cover && dsack==1
Undo=undo-1
endif

"Phase 2-1-1-1: Processing interval 1 (as shown in the opening diagram) Sack (dsack), where the packet will be deleted next"
If P[J]. Right < UNA | | P[J]. right = UNA
If P[J] has been re-transmitted
If Dsack==1 && P[j] is covered by S[i && P[j] has been sack
"Update Chaos 1: Retransmission, was sack, and was sack, indicating that the original package is not lost, passed two times, get two times sack, need to record the package location"
Reord=min (Fack,reord)
else If ...
"Small problem: if it is only retransmission, but has not been sack, indicating that this dsack is the first time the packet is confirmed, can also be aggressively identified as a disorderly order and update the Reord value?? "
endif
Else
If Fack < the highest sack position && P[j] has never been sack
"Update Chaos 2: The P[j] is in a hole"
"This means that the p[j] is the ACK confirmed by the advance, which has never been sack before, stating that the disorder was detected"
Reord=min (Fack,reord)
endif
endif
Continue stage 2-1-1"This interval 1 package will be clean, continue to the next"
endif

"Stage 2-1-1-2: Processing interval 2 (as shown in the opening diagram), this process is relatively simple, routine scanning, sacked bit"
If P[J] not covered by s[i]
Continue stage 2-1-1
endif

If P[j].sack = = 0
"The new sack confirmed the segment marked as Lost/retrans, stating that the retransmission was successful."
If P[J] has been labeled lost && P[j] has been re-transmitted
Clear the Lost and Retrans marks of P[j]
Lost_out=lost_out-1
Retrans_out=retrans_out-1
endif

If P[J] is not tagged for retransmission && fack < highest sack position
"What this means is that the sack of the P[j] is the original packet, and is sack after the highest sack package, the naked mess! "
"Update Chaos 3: In the interval 2 is the highest sack package before the hole is filled (reverse is sack), note that the filling is not caused by retransmission, but the original packet arrival caused by chaos"
Reord=min (Fack,reord)
endif
P[j].sack=1
Sack_out=sack_out+1
Else
if dsack = = 1 && p[j] has been re-transmitted
"Update Chaos 4: In Interval 2 was detected dsack (a sack block is contained or coincident with another block), and the current P[J] under the cover of S[0]"
"P[j" was re-transmitted, and obtained sack, at this time s[0] carried Dsack again confirmed it (while S[1] will also confirm it, because S[1] contains s[0]), detected a disorderly sequence "
Reord=min (Fack,reord)
Retrans_out=retrans_out-1
endif
endif
ENDfor
Dsack=0handling Dsack "only at S[0]"
ENDfor


Note that this is the first part of the first scan in the 4 scans of the transmit queue when the TCP sender receives an ACK, and the following tasks are in the first scan:

a). Flag which packets that have been re-transmitted may be lost
b). Update the reordering of the network disorderly order

is not included in algorithm a!


It is also worth noting that the following algorithms are available, but not optimal. We see the algorithm involved in the two-layer traversal, one for sack block, the other for the transmission queue is still not purged packets, the algorithm does not sack block sorting and skip optimization, the purpose of this is to be simple readability, you can understand the fastest speed of the approximate, Then go and pick up the details.

2. Data receiving end of sack processing this is relatively simple, my advice is to read through RFC2018 "TCP selective acknowledgment Options", however, I would like to be based on this RfC, in this article to extract some important things. Note that section 4, which describes the behavior of the receiving end, together with other criteria, is summed up as follows:
2.1. The first sack block of the construction of the first sack block must accurately react to the ordered packets that have just been received, taking into account the following sequence: rcv1|rcv2|hole|rcv3|hole|rcv4, if the chaos received Rcv4 and RCV3,RCV4 is before the chaotic order received, the current chaos Order received rcv3, then in the construction of sack block, the first block is rcv3.
2.2.SACK block to include which packet receiver to include as much as possible in the SACK block to contain the packets that have been ordered out of order, until the length of TCP option is reached, the order of these blocks to indicate "which packets recently received", the more recent packets received ( The wording is not accurate, according to the TCP standard, should say is the data section! Should be in the front, this is similar to the principle of the LRU list. This helps the data sender to make precise decisions.
2.3. When the receiving end responds with the ACK standard of sack block, the ACK must be restored immediately when any data is received, even if the delay ACK is enabled, as long as there is a disorderly order packet in the receiving queue.

An example in 3.RFC is extremely extensible

The left window Edge serial number is 5000, transmits 8 packets, MSS is 500, as follows:

p0:4500-4999| p1:5000-5499| p2:5500-5999| p3:6000-6499| p4:6500-6999| p5:7000-7499| p6:7500-7999| p7:8000-8499| p8:8500-8999|
Now P2,P4,P6,P8 lost:
| p1:5000-5499| P2:lost| p3:6000-6499| P4:lost| p5:7000-7499| P6:lost| p7:8000-8499| P8:lost|


The P1,P3,P5,P7 is successfully received, where P1 is received sequentially, so the ACK is pushed forward, and the P3,P5,P7 is ordered to be received, so a repeat ACK for 5500 is carried sack, as shown in:





Imagine that P4 is being ordered to receive the scene, it will fill the void between P3 and P5, will p3-p5 into a piece, in order to show "recently Sack", P3 (6000-6499)-P5 (7000-7499) will be set to sack block the first block, that is (6000 ---7500) as shown in:




P2 is also being ordered to receive at this time (assuming it is not lost, just multipath delay chaos arrives), this time the ACK can be pushed forward to 7500, which means that this P6 (7500-7999) is the next packet to receive, and because there is a P7 in the Chaos Queue (8000-8499), So this ACK to 7500 confirmation packet carries a unique sack block (8000-8499) back to the data sender, which is recorded as ACK7500, as shown in:




Next we look at the situation of Dsack, when will deal with the interval 1 (as shown in the opening diagram) of the sack?

p0:4500-4999| p1:5000-5499| p2:5500-5999| p3:6000-6499| p4:6500-6999| p5:7000-7499| p6:7500-7999| p7:8000-8499| p8:8500-8999|
At this point P0,p1,p2,p4,p6,p8 is lost, except for the P1 and RFC examples and the introduction of new P0, other and RFC examples are consistent. Consider the duplicate ACK, that is, ACK4500 has reached the sender and has triggered a retransmission, and retransmission p0,p1,p2, and P2 successfully reached the receiving end, P0,p1 did not arrive, at this time the sack block will contain P2, received by the sender will be set P2 for sacked, At this time received p0,p1,ack forward to 6500 (P4 lost, P3 originally did not lose, was sack), recorded as ACK6500, but at this time ACK6500 lost, did not reach the sending end, at this time, the original P2 also arrived, note that the P2 originally did not lose, It is possible that the retransmission of the P2 has been received and has been sack because of the multipath delay. At this time the receiver found P2 on the left side of ACK6500, and ACK6500 has already issued (the receiver is not aware of the loss of ACK), so it will be considered a dsack, so will construct the following dsack to carry ack6500d:



When the above ack6500d arrives at the sending end, execute algorithm A, at which time prior Una is 5500,una 6500, and s[0]. Right is 5500, less than Una, will enter the processing of interval 1, processing details, see Algorithm A (note the small problem in algorithm a)

The sequence above is a bit complex, and in most cases, the probability of this happening is relatively low, unless the network is very chaotic, most of the following two classes:

a). Repeated ACK carries sack: At this time the prior Una and una are equal;
b). The forward ACK carried the sack,sack only in the interval 2.



4. Update the details of the network chaos reordering in the first part of algorithm A, we record a variable Reord that represents the location of the packet (relative to the head of the transmission queue) in the leftmost sack/dsack of the transmission queue, as shown in the diagram on the opening, prior The Una and una divide the transmission queue into the following scenarios:
1). Dsack falls in the interval 0.

reordering is not updated. Since all packets of this interval have been confirmed and cleared from the transmission queue, there is no way to detect the previous behavior of the packet through some of its flags, such as whether it has been re-transmitted, marked as sack, etc.


2). Dsack fall in the interval 1 there are two situations to consider:
2.1). Prior una and una are equal to repeat ACK cases. At this time the interval 1 collapses, its front is the interval 0, the reason is same as above processing interval 0 dsack, does not update the reordering.
2.2). Prior una is less than unaack forward to advance the UNA situation. There are two cases of detection of chaos, one is the interval 1 packets are re-transmitted and received sack, and now receive the Dsack, which indicates that the original packet was not lost, the situation of the reordering update as shown:




In another case, it is found that a packet of this interval is always a void before the UNA advances, neither sack nor re-transmitted, and Una advanced before it was sack by the highest packet before it, stating that it was Ack is the current Una propulsion, after which the packets are sack, It was not until now that the ACK, stating that there was a disorderly order, reordering the update as shown:



3). Dsack fall in the interval 2 interval 2 of the chaos Detection also has two cases. The first is the case where a hole in front of the highest sack packet is found to be filled, and the void has never been re-transmitted or sack, as shown:




In the second case, it is found that a packet in Interval 2 has been re-transmitted, and has been marked as sack, indicating the success of the retransmission or the original packet reached the receiving end, but the present one dsack again confirmed it, this means there must be two p[j] reached the end, the sender of a total of two, A primitive p[j], a retransmission p[j], indicating that the original packet is not lost, disorderly order.



5. What to do if you receive a una prior to the ACK. In this case, it is most straightforward to throw away, but think about it, the confirmation package can still get some information from it, such as:
a). You can get some information about Dsack from its sack block, which may allow us to discover the chaotic order of the network and decrement the undo counter, thus directing us to undo operations in a congested state;
b). You can follow the RFC3517 in section 5 (C) routine brush retransmission queue, its nextseg routine may return a series of data, and then send:
The ACK value was considered acceptable only if it was in the range of (SND. Una-max. Snd. WND) <= SEG. ACK <= SND. NXT).

It is important to note that, in the implementation of the Linux protocol stack, Tcp_xmit_retransmit_queue does not actually send new data, it simply returns when no data marked as lost is sent but there is new data waiting to be sent! Then the task of sending the new data is sent by the sending path when it is the turn to run.


But what does that mean, do you notice? This is likely to bring security problems! If we look at algorithm A, we find that there are two layers of loops, the time complexity of their own calculation will know, even if the optimization version is not where to go. If a malicious person constructs some of the packets carrying sack to the network, the transmission queue is very large and will make the algorithm a (or any optimization version [just add some sort, skip ...]) Consumes a huge amount of CPU time, so receiving a Una ack before expecting to be able to use this idea for me is both pros and cons. So RFC5961 a tradeoff, that is, in the Una before a window of the ACK is available, a window outside the data distance is too far away, it will be considered a replay attack, directly discarded.


6. I am how to apply to the time the answer of course is reported progress, to tell his wife this time will gain what proceeds, then she will ask, now how the situation, answer, and then ask what difficulties encountered, answer, continue to ask, when can be completed, reply, ... If one does not answer well, basic do not hard resistance, or go to the floor to buy food cooking brush Bowl, is also a good experience, until the end of the weekend, you can write a recipe to share to everyone, is also a relatively fruitful.

In any case, there is work in the eye, God in mind, this Protestant belief I think is the origin of the European civilization after the blooming .... A bit far away, but still want to buy vegetables ...
... This is 10 O ' Day in the morning ...

TCP's handling of sack and the processing details of the chaotic sequence

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.