CN108650064A - A kind of effective retransmission detection data-bag lost simultaneously prevents retransmission time out method - Google Patents
A kind of effective retransmission detection data-bag lost simultaneously prevents retransmission time out method Download PDFInfo
- Publication number
- CN108650064A CN108650064A CN201810432428.1A CN201810432428A CN108650064A CN 108650064 A CN108650064 A CN 108650064A CN 201810432428 A CN201810432428 A CN 201810432428A CN 108650064 A CN108650064 A CN 108650064A
- Authority
- CN
- China
- Prior art keywords
- data packet
- sack
- snd
- mem
- flag
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 14
- 238000001514 detection method Methods 0.000 title claims abstract description 11
- 238000012545 processing Methods 0.000 claims description 13
- 230000002159 abnormal effect Effects 0.000 claims description 7
- 230000014509 gene expression Effects 0.000 claims description 7
- 238000010009 beating Methods 0.000 claims description 3
- 238000005111 flow chemistry technique Methods 0.000 claims description 3
- 238000007689 inspection Methods 0.000 claims description 3
- 239000003550 marker Substances 0.000 claims description 3
- 230000001960 triggered effect Effects 0.000 abstract 1
- 230000005540 biological transmission Effects 0.000 description 5
- 238000011084 recovery Methods 0.000 description 4
- 230000000875 corresponding effect Effects 0.000 description 2
- 230000009191 jumping Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000003044 adaptive effect Effects 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000002474 experimental method Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
The invention discloses a kind of effective retransmission detection data-bag lost and prevent retransmission time out method, belongs to mobile network field.The present invention obtains each SACK that receiving terminal returns to transmitting terminal in transmitting terminal first；Then each section of SACK is traversed, is compared and previous SACK sections of difference；Finally judged to retransmit whether data packet loses according to the comparison result of previous step, if it is judged that being retransmitted again to lose so to trigger, and prevents retransmission time out.This invention ensures that caused by complicated network environment under high packet loss situation, the loss again for retransmitting data packet can be detected effectively, and is triggered transmitting terminal and retransmitted again, and network throughput is improved.
Description
Technical field
The present invention relates to a kind of effective retransmission detection data-bag lost and prevent retransmission time out method, belongs to mobile network's neck
Domain.
Background technology
New performance bottleneck is encountered in high-speed mobile network as widely used Transmission Control Protocol.For example, Mascolo
Et al. also have Fu and Liew devise new method to distinguish non-congested packet loss and the congestion packet loss in network, prevent unnecessary
Reducing congestion window causes bandwidth availability ratio to lose.Also someone improves losing retransmission phase redesign congestion avoidance algorithm
The bandwidth availability ratio of TCP.Liu and Lee also have Leong et al. propose the adaptive loss recovery algorithm based on queue length come
Replace the loss recovery algorithm in original TCP, they decouple data-bag lost and congestion control, make transmission rate or congestion window
The adjustment of mouth is only influenced by the link queue length assessed when retransmitting or sending new packet.They are in loss recovery rank
The adjustment transmission rate of Duan Chixu sends window to make queue length surrounding target queue length value fluctuate.Compare biography
The TCP algorithms of system, theirs the results show that the band caused by random loss in a mobile network can be effectively relieved in their method
Wide utilization rate declines problem.
Further to improve bandwidth availability ratio, Zha and Liu propose opportunistic retransmission algorithm-OR and new transmission is slow
Area's dynamic allocation scheme is deposited, performance bottleneck and application caused by the flow control to solve the Fast retransmission stage respectively
Stall problems.Flow control bottleneck is mainly due to the loss recovery stage in TCP, if the reception window of recipient is consumed
To the greatest extent, such Awnd can prevent the transmission of new data packets, cause link idle, to make bandwidth availability ratio decline.Application
Stall problems are then since network allows TCP senders to continue to send new data packets, but sender does not have new data packets that can send out
It send, this problem is referred in the research of Dukkipati et al. and in the BBR of Google.
In experiment, in the environment of network bandwidth is 20Mbps, from the point of view of test data, the bandwidth of Zha and Liu schemes
Utilization rate can reach 95.0%, it appears that well solved the bandwidth availability ratio brought in loss recovery stage random loss and declined
Problem.However, when we promote network bandwidth to 100Mbps, it has been found that new problem --- it is frequent retransmit it is super
When-RTO, cause bandwidth availability ratio to can only achieve 50% or so.
Invention content
The technical problem to be solved in the present invention is to provide a kind of effective retransmission detection data-bag lost and prevent retransmission time out
Method ensure that can there there be the loss again for retransmitting data packet caused by complicated network environment under high packet loss situation
The detection of effect, and trigger transmitting terminal and retransmit again, improve network throughput.
The technical solution adopted by the present invention is：A kind of effective retransmission detection data-bag lost simultaneously prevents retransmission time out method,
Include the following steps：First each SACK that receiving terminal returns to transmitting terminal is obtained in transmitting terminal；Then traversal SACK's is every
One section, compare and previous SACK sections of difference；Finally judged to retransmit whether data packet loses according to the comparison result of previous step,
If it is judged that being retransmitted again to lose so to trigger, and prevent retransmission time out.
Above-mentioned steps are specific as follows：
Step1：Intercepting and capturing receiving terminal returns to each of transmitting terminal before the linux kernel processing SACK of transmitting terminal
SACK；
Setp2：The flag bit flag of SACK is detected, in linux kernel, the flag of SACK represents corresponding data packet
State；
Step3：By the data packet flag bit expression formula FLAG_NOT_DUP in the flag bit flag of SACK and linux kernel
Or FLAG_SND_UNA_ADVANCED or FLAG_DATA_SACKED do logical AND operation, and FLAG_NOT_DUP expressions receive
SACK be not a repetition SACK, FLAG_SND_UNA_ADVANCED indicates that the SACK received has updated reception window-
The start sequence number of Awnd, FLAG_DATA_SACKED indicates that SACK confirmed new data packet, if the condition of logical AND is true,
Then indicate that current SACK and the upper SACK received are just the same, it is meant that retransmitting data packet may lose, then entering
Step4 is further to be judged；If the condition of logical AND is false, it is normal to represent the SACK, need not be located
Reason, so jumping to Step11, directly gives linux kernel and carries out re-transmission packet inspection according to normal flow；
Step4：Known by Step3, which is abnormal SACK, then calls kernel function tcp_for_write_
Queue_from traverse transmitting terminal cache snd_mem, every time transmit a snd_mem data packet pointer _ skb to Step5 at
Reason judges whether to need to be retransmitted；
Step5：If the highest that the data packet of current snd_mem is more than snd_mem records has sent sequence number highest_
Sack_sequence, expression have had stepped through snd_mem, have then jumped to Step11；If the data packet of current snd_mem
Highest less than or equal to snd_mem records has sent sequence number highest_sack_sequence, indicates snd_mem not yet time
End is gone through, then jumps to that Step6 is further to current data packet to be judged；
Step6：If current data packet is crossed by SACK, indicate that receiving end has received the data packet, no
It needs to retransmit, then the Step4 without any processing that jumps to continues to traverse snd_mem；If the data packet not by SACK, that
It indicates that the data packet may have lost, needs to be retransmitted, then jump to Step7 and judge to retransmit the mark that a data packet needs
Whether will has all been stamped；
Step7：Data packet is judged either with or without being marked as losing, and if there is stamping TCPCB_LOST labels, represents Linux
Kernel has been marked as being lost, and need not be handled, thus jump to Step9 continue to judge to retransmit data packet its
Whether he condition meets；But if not labeled, it is necessary to TCPCB_LOST labels are stamped to the data packet, because not beating
TCPCB_LOST is marked, and linux kernel will be considered that the data packet is not lost, would not also be retransmitted that such receiving terminal is just
The data packet that can not receive this loss always, until Retransmission timeout；
Step8：TCPCB_LOST labels are stamped to data packet, Step9 is then branched to and continues to determine whether to meet re-transmission
Condition；
Step9：If having beaten TCPCB_SACKED_RETRANS labels, indicate that the data packet had been retransmitted, no matter
Whether data packet loses again, and linux kernel will not all retransmit the data packet again, so if linux kernel does not give the number
According to packet making TCPCB_SACKED_RETRANS, indicates that the data packet can be retransmitted, any processing need not be done, jumped directly to
Step4 continues to traverse snd_mem；If data packet is marked with TCPCB_SACKED_RETRANS, Step10 is jumped to
It continues with；
Step10：The TCPCB_SACKED_RETRANS marker bits of data packet are disposed, Step4 continuation is then branched to
Traverse snd_mem；
Step11：The abnormal SACK of normal SACK either after treatment finally can be submitted to re-transmission function,
According to normal linux kernel flow processing, the data packet for needing to be retransmitted then is retransmitted.
The present invention operation principle be：SACK is intercepted and captured before the SACK that transmitting terminal processing receives, detects the flag bit of SACK
Judge whether SACK is normal SACK, it is if it is normal SACK, then without any processing and exit linux kernel is allowed normally to handle
Change SACK, but if abnormal, then traverse snd_mem, checks the flag bit of data packet in snd_mem one by one, judge whether to need
It is retransmitted.
The present invention benefit be：Using the present invention overcomes be raising network throughput in the mobile network of environment complexity
Introduce the frequent retransmission time out problem that OR algorithms are brought.SACK is received by detecting transmitting terminal in advance, changes data in snd_mem
The flag bit of packet enables to be retransmitted by the data packet that linux kernel retransmits originally, and avoiding network, frequently re-transmission is super
When, improve the throughput of network.
Description of the drawings
Fig. 1 is the flow chart of the present invention；
Fig. 2 is the Status Flag figure of flag；
Fig. 3 is the reception window figure that packet loss occurs and does not use OR algorithms；
Fig. 4 is the reception window figure that the OR algorithms that packet loss uses occur；
Fig. 5 is to receive to retransmit the reception window figure that data packet does not use OR algorithms；
Fig. 6 is to receive to retransmit the reception window figure that data packet uses OR algorithms.
Specific implementation mode：
In order to describe in more detail the present invention and convenient for the understanding of those skilled in the art, below in conjunction with the accompanying drawings and embodiment pair
The present invention does the description into one, and the embodiment of this part for illustrating the present invention, with this do not come by the purpose being easy to understand
The limitation present invention.
Embodiment 1：As shown in figures 1 to 6, a kind of effective retransmission detection data-bag lost and prevent retransmission time out method, including
Following steps：First each SACK that receiving terminal returns to transmitting terminal is obtained in transmitting terminal；Then each section of SACK is traversed,
Compare and previous SACK sections of difference；Finally judged to retransmit whether data packet loses according to the comparison result of previous step, if
It predicates to lose so to trigger and retransmit again, and prevent retransmission time out.
Above-mentioned steps are specific as follows：
Step1：Intercepting and capturing receiving terminal returns to each of transmitting terminal before the linux kernel processing SACK of transmitting terminal
SACK；
Setp2：The flag bit flag of SACK is detected, in linux kernel, the flag of SACK represents corresponding data packet
State.We use linux kernel 3.12 editions, the version to share 17 kinds of states, each state has the meaning of their own,
Status Flag and value are shown in Fig. 2；
Step3：Reception window-Awnd of OR algorithms is not used as shown in figure 3, there are two packet losses for display in figure, and send
It is more than never the right margin of Awnd to hold the data packet maximum serial number that can be sent, and after OR algorithms, transmitting terminal can be sent
Additional data packet, Awnd is as shown in figure 4, equally there are two packet losses at this time.It will be in the flag bit flag of SACK and linux kernel
Data packet flag bit expression formula FLAG_NOT_DUP or FLAG_SND_UNA_ADVANCED or FLAG_DATA_SACKED
Logical AND operation (see Fig. 1) is done, FLAG_NOT_DUP indicates that the SACK received is not repetition a SACK, FLAG_SND_UNA_
ADVANCED indicates that the SACK received has updated the start sequence number of Awnd, and it is new that FLAG_DATA_SACKED indicates that SACK confirmed
Data packet, if the condition of logical AND is true, then it represents that current SACK and the upper SACK received are just the same, it is meant that weight
Passing data packet may lose, and Awnd is there is no sliding to the right, and the left margin of Awnd is not always by that by the data packet of SACK
It blocks, Awnd into Step4 is further as shown in fig. 6, so judged；If the condition of logical AND is false, at this moment Awnd
As shown in figure 5, Awnd has been slided into the right at the start sequence number of next packet loss, then it is normal to represent the SACK, it is not required to
Want it is proposed that method handled, so jump to Step11, directly give linux kernel and carry out weight according to normal flow
Pass packet inspection；
Step4：Known by Step3, which is abnormal SACK, and then we call kernel function tcp_for_
Write_queue_from traverses transmitting terminal caching-snd_mem, transmit every time the pointer-of the data packet of a snd_mem _
Skb gives Step5 processing, judges whether to need to be retransmitted；
Step5：Pass through TCP_SKB_CB (_ skb)->The serial number for the data packet that seq taking-ups _ skb is directed toward, if currently _
The data packet serial number that skb is directed toward snd_mem is more than or equal to the highest of snd_mem records by the data packet serial number-of SACK
Highest_sack_sequence, then it represents that had stepped through snd_mem, then jumped to Step11；If condition is false,
It indicates that there are no traversals to terminate by snd_mem, then jumps to that Step6 is further to the current data packet of taking-up to be judged；
Step6：If the data packet that current _ skb is directed toward is crossed by SACK, the data packet receiving end is indicated
It has received, need not be retransmitted, then without any processing jump to Step4, pass through function tcp_for_write_
Queue_from (_ skb, sk), _ skb are directed toward next data packet of snd_mem；If the data packet not by SACK,
It indicates that the data packet may have lost, needs to be retransmitted, then jump to Step7 and judge to retransmit the mark that a data packet needs
Whether all stamp；
Step7：Pass through TCP_SKB_CB (_ skb)->The data packet that sacked＆TCPCB_LOST operation judges _ skb is directed toward
Either with or without being marked as losing, if there is stamping TCPCB_LOST labels, represents linux kernel and have been marked as being lost, no
It needs us to handle, continues to judge whether the other conditions for retransmitting a data packet meet so jumping to Step9；But
If not labeled, we just need to stamp TCPCB_LOST labels to the data packet, because not beating TCPCB_LOST labels,
Linux kernel will be considered that the data packet is not lost, and would not also be retransmitted, and such receiving terminal just can not receive always this and lose
The data packet of mistake, until Retransmission timeout；
Step8：TCPCB_LOST labels are stamped to data packet, marking operation is TCP_SKB_CB (_ skb)->sacked
|=TCPCB_LSOT, and also add 1, lost_out to record data-bag lost in linux kernel variable lost_out
Number then branches to Step9 and continues to determine whether to meet the condition retransmitted；
Step9：If having beaten TCPCB_SACKED_RETRANS labels, indicate that the data packet had been retransmitted, no matter
Whether data packet loses again, and linux kernel will not all retransmit the data packet again.So if linux kernel does not give the number
It according to packet making TCPCB_SACKED_RETRANS, indicates that the data packet can be retransmitted, does not need us and do any processing, directly jump
Step4 is gone to continue to traverse snd_mem；If data packet is marked with TCPCB_SACKED_RETRANS, jump to
Step10 is continued with；
Step10：The TCPCB_SACKED_RETRANS marker bits of data packet are disposed, clear operation TCP_SKB_
CB(_skb)->Sacked＆=~TCPCB_SACKED_RETRANS, while variable retrans_out is subtracted 1, retrans_
Out indicates the number of the data packet currently retransmitted, because when retransmitting again, linux kernel can again will automatically
Retrans_out adds 1.Step4 is then branched to continue to traverse snd_mem.
Step11：The abnormal SACK of normal SACK either after treatment finally can be submitted to re-transmission function,
According to normal linux kernel flow processing, the data packet for needing to be retransmitted is retransmitted, and plus-minus behaviour is carried out to correlated variables
Make.
The present invention proposes through the SACK that is received in transmitting terminal of detection, the reason of to judge data-bag lost, and with module
Form modification snd_mem in not by the flag bit of the data packet of SACK, then trigger TCP senders and retransmit data again
Packet, the method can effectively solve the problems, such as frequent retransmission time out, increase substantially network bandwidth utilization factor.
The present invention need to only make linux kernel the modification of very little, and can insert the method for proposition in modular form
Enter to linux kernel, original linux kernel will not be impacted.
The specific implementation mode of the present invention is explained in detail above in association with attached drawing, but the present invention is not limited to above-mentioned
Embodiment within the knowledge of a person skilled in the art can also be before not departing from present inventive concept
Put that various changes can be made.
Claims (2)
1. a kind of effective retransmission detection data-bag lost simultaneously prevents retransmission time out method, it is characterised in that：Include the following steps：It is first
First each SACK that receiving terminal returns to transmitting terminal is obtained in transmitting terminal；Then traverse each section of SACK, compare with it is previous
A SACK sections of difference；Finally judged to retransmit whether data packet loses according to the comparison result of previous step, if it is judged that lose
It so triggers and retransmits again, and prevent retransmission time out.
2. effective retransmission detection data-bag lost according to claim 1 simultaneously prevents retransmission time out method, it is characterised in that：
It is as follows：
Step1：Each SACK that receiving terminal returns to transmitting terminal is intercepted and captured before the linux kernel processing SACK of transmitting terminal；
Setp2：The flag bit flag of SACK is detected, in linux kernel, the flag of SACK represents the shape of corresponding data packet
State；
Step3：By the data packet flag bit expression formula FLAG_NOT_DUP or in the flag bit flag of SACK and linux kernel
FLAG_SND_UNA_ADVANCED or FLAG_DATA_SACKED do logical AND operation, and FLAG_NOT_DUP expressions receive
SACK is not that repetition a SACK, FLAG_SND_UNA_ADVANCED indicate that the SACK received has updated reception window-Awnd
Start sequence number, FLAG_DATA_SACKED indicate SACK confirmed new data packet, if the condition of logical AND is true, table
Show that current SACK and the upper SACK received are just the same, it is meant that retransmitting data packet may lose, then being done into Step4
It is further to judge；If the condition of logical AND is false, it is normal to represent the SACK, need not be handled, so
Step11 is jumped to, linux kernel is directly given and carries out re-transmission packet inspection according to normal flow；
Step4：Known by Step3, which is abnormal SACK, then calls kernel function tcp_for_write_queue_
From traverses transmitting terminal and caches snd_mem, and the pointer _ skb for transmitting a snd_mem data packet every time gives Step5 processing, judges
Whether need to be retransmitted；
Step5：If the highest that the data packet of current snd_mem is more than snd_mem records has sent sequence number highest_sack_
Sequence, expression have had stepped through snd_mem, have then jumped to Step11；If the data packet of current snd_mem is less than etc.
It has sent sequence number highest_sack_sequence in the highest of snd_mem records, has indicated that there are no traversals to terminate by snd_mem,
Then jump to that Step6 is further to current data packet to be judged；
Step6：If current data packet is crossed by SACK, indicate that receiving end has received the data packet, does not need
It retransmits, then the Step4 without any processing that jumps to continues to traverse snd_mem；If the data packet is not by SACK, table
Show that the data packet may have lost, need to be retransmitted, then jumps to Step7 and judge that retransmitting the mark that a data packet needs is
It is no all to have stamped；
Step7：Data packet is judged either with or without being marked as losing, and if there is stamping TCPCB_LOST labels, represents linux kernel
Have been marked as being lost, need not be handled, thus jump to Step9 continue to judge to retransmit data packet other
Whether part meets；But if not labeled, it is necessary to TCPCB_LOST labels are stamped to the data packet, because not beating TCPCB_
LOST is marked, and linux kernel will be considered that the data packet is not lost, would not also be retransmitted that such receiving terminal is just received always
Less than the data packet of this loss, until Retransmission timeout；
Step8：TCPCB_LOST labels are stamped to data packet, Step9 is then branched to and continues to determine whether to meet the item retransmitted
Part；
Step9：If having beaten TCPCB_SACKED_RETRANS labels, indicate that the data packet had been retransmitted, no matter data
Whether packet is lost again, and linux kernel will not all retransmit the data packet again, so if linux kernel does not give the data packet
TCPCB_SACKED_RETRANS is marked, indicates that the data packet can be retransmitted, any processing need not be done, jumped directly to
Step4 continues to traverse snd_mem；If data packet is marked with TCPCB_SACKED_RETRANS, Step10 is jumped to
It continues with；
Step10：The TCPCB_SACKED_RETRANS marker bits of data packet are disposed, Step4 is then branched to and continues to traverse
snd_mem；
Step11：The abnormal SACK of normal SACK either after treatment finally can be submitted to re-transmission function, according to
Normal linux kernel flow processing, then retransmits the data packet for needing to be retransmitted.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810432428.1A CN108650064A (en) | 2018-05-08 | 2018-05-08 | A kind of effective retransmission detection data-bag lost simultaneously prevents retransmission time out method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810432428.1A CN108650064A (en) | 2018-05-08 | 2018-05-08 | A kind of effective retransmission detection data-bag lost simultaneously prevents retransmission time out method |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN108650064A true CN108650064A (en) | 2018-10-12 |
Family
ID=63749334
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810432428.1A Pending CN108650064A (en) | 2018-05-08 | 2018-05-08 | A kind of effective retransmission detection data-bag lost simultaneously prevents retransmission time out method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108650064A (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111953568A (en) * | 2020-08-19 | 2020-11-17 | 杭州迪普科技股份有限公司 | Method and device for managing packet loss information |
| CN115085890A (en) * | 2022-06-23 | 2022-09-20 | 杭州云合智网技术有限公司 | Method for optimizing TCP RTO retransmission waiting time by data center network chip |
| EP4207654A4 (en) * | 2020-09-17 | 2023-09-27 | Huawei Technologies Co., Ltd. | Packet retransmission method and apparatus |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102761403A (en) * | 2012-06-28 | 2012-10-31 | 深信服网络科技（深圳）有限公司 | Method and device for detecting TCP (transmission control protocol) packet loss and TCP stack |
| CN103546245A (en) * | 2013-11-05 | 2014-01-29 | 重庆邮电大学 | Data packet retransmission method based on network codes |
| CN104104480A (en) * | 2014-07-31 | 2014-10-15 | 北京蓝汛通信技术有限责任公司 | Method and device for detecting retransmission packet loss of TCP (transmission control protocol) |
-
2018
- 2018-05-08 CN CN201810432428.1A patent/CN108650064A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102761403A (en) * | 2012-06-28 | 2012-10-31 | 深信服网络科技（深圳）有限公司 | Method and device for detecting TCP (transmission control protocol) packet loss and TCP stack |
| CN103546245A (en) * | 2013-11-05 | 2014-01-29 | 重庆邮电大学 | Data packet retransmission method based on network codes |
| CN104104480A (en) * | 2014-07-31 | 2014-10-15 | 北京蓝汛通信技术有限责任公司 | Method and device for detecting retransmission packet loss of TCP (transmission control protocol) |
Non-Patent Citations (1)
| Title |
|---|
| 万文凯等: "移动网络中重传超时问题的研究", 《软件》 * |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111953568A (en) * | 2020-08-19 | 2020-11-17 | 杭州迪普科技股份有限公司 | Method and device for managing packet loss information |
| EP4207654A4 (en) * | 2020-09-17 | 2023-09-27 | Huawei Technologies Co., Ltd. | Packet retransmission method and apparatus |
| CN115085890A (en) * | 2022-06-23 | 2022-09-20 | 杭州云合智网技术有限公司 | Method for optimizing TCP RTO retransmission waiting time by data center network chip |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11799790B2 (en) | Data transmission method, computing device, network device, and data transmission system | |
| KR102249741B1 (en) | Method and apparatus for data transmission | |
| US6535482B1 (en) | Congestion notification from router | |
| RU2691240C1 (en) | Packet transmission method and a subscriber device | |
| US6741555B1 (en) | Enhancement of explicit congestion notification (ECN) for wireless network applications | |
| Iyengar et al. | Concurrent multipath transfer using SCTP multihoming | |
| JP4016387B2 (en) | Data flow control method | |
| CA2358396C (en) | Communication device and method | |
| EP1295428B1 (en) | Performance enhancement of transmission control protocol (tcp) for wireless network applications | |
| US7369498B1 (en) | Congestion control method for a packet-switched network | |
| EP1691526A1 (en) | Transmission control protocol (TCP) congestion control using multiple TCP acknowledgements (ACKs) | |
| US20130250767A1 (en) | Method and Device for Data Transmission | |
| CN107204834A (en) | A kind of control method of the express network transmitting based on UDT agreements | |
| CA2237264A1 (en) | Receiver based congestion control | |
| US20100226384A1 (en) | Method for reliable transport in data networks | |
| CN108650064A (en) | A kind of effective retransmission detection data-bag lost simultaneously prevents retransmission time out method | |
| CN108965322A (en) | Spatial network transmission control protocol | |
| Zhou et al. | Demystifying and mitigating TCP stalls at the server side | |
| Zhou et al. | TCP stalls at the server side: Measurement and mitigation | |
| US20050039075A1 (en) | Receiving device, transmitting device and programs | |
| US9510242B2 (en) | Reducing superfluous traffic in a network | |
| JP2006173961A (en) | Tcp convergence control system in wide band, high delay radio network | |
| Dalal et al. | Link layer correction techniques and impact on TCP’s performance in IEEE 802.11 wireless networks | |
| CN108322402B (en) | Message processing method, device and system | |
| EP3031159B1 (en) | Retransmission control network node and related method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20181012 |
|
| RJ01 | Rejection of invention patent application after publication |