저작자표시-비영리-변경금지 2.0 대한민국 이용자는 아래의 조건을 따르는 경우에 한하여 자유롭게
l 이 저작물을 복제, 배포, 전송, 전시, 공연 및 방송할 수 있습니다. 다음과 같은 조건을 따라야 합니다:
l 귀하는, 이 저작물의 재이용이나 배포의 경우, 이 저작물에 적용된 이용허락조건 을 명확하게 나타내어야 합니다.
l 저작권자로부터 별도의 허가를 받으면 이러한 조건들은 적용되지 않습니다.
저작권법에 따른 이용자의 권리는 위의 내용에 의하여 영향을 받지 않습니다. 이것은 이용허락규약(Legal Code)을 이해하기 쉽게 요약한 것입니다.
Disclaimer
저작자표시. 귀하는 원저작자를 표시하여야 합니다.
비영리. 귀하는 이 저작물을 영리 목적으로 이용할 수 없습니다.
변경금지. 귀하는 이 저작물을 개작, 변형 또는 가공할 수 없습니다.
Master's Thesis
Zero Retransmission Transport with Proactive FEC
Seongsik Cho
Department of Computer Science and Engineering
Ulsan National Institute of Science and Technology
[UCI]I804:31001-200000374086 [UCI]I804:31001-200000374086 [UCI]I804:31001-200000374086 [UCI]I804:31001-200000374086
2021
Zero Retransmission Transport with Proactive FEC
Seongsik Cho
Department of Computer Science and Engineering
Ulsan National Institute of Science and Technology
Zero Retransmission Transport with Proactive FEC
A thesis/dissertation submitted to
Ulsan National Institute of Science and Technology in partial fulfillment of the
requirements for the degree of Master of Science
Seongsik Cho
2020/12/18 Approved by
_________________________
Advisor
Youngbin Im
Zero Retransmission Transport with Proactive FEC
Seongsik Cho
This certifies that the thesis/dissertation of Seongsik Cho is approved.
2020/12/18
Signature
___________________________
Advisor: Youngbin Im Signature
___________________________
Kyunghan Lee Signature
___________________________
Hyoil Kim
1
Abstract
Upcoming fourth industries demand low latency in many ways. One of them is the remote control industry combined with the 5G infrastructure, which already has a lot in place, including remote surgery or remote heavy machine control to work day and night alternatively.
Intercontinental remote control industries have a lot of safety concerns, so there is a particular need for stronger latency bound. Many latest low-latency works mostly aim to keep queuing low and ensure low latencies of 99.0% to 99.9% percent packets, but has weaknesses on 0.1%
packets tail latencies due to retransmission which trigger RTT-sensitive delay and RTO. To
prevent further delays due to this retransmission problem, many researchers have been working
on FEC that can recover packet loss in half RTT without retransmission. Packet level FEC is
basically a method of protecting traffic from loss, by encoding packets with adding
redundancies. Many XOR, Block, or sliding window code based FEC were studies before, but
they could not overcome the basic limitations of their code due such as low recovery ratio or
high overhead by poor adaptiveness. In order to achieve higher FEC performance on state-
varying channels, near real time level adaptability was essential, so we designed a method to
learn future loss pattern on deep learning model to determine FEC parameters. As a result of
increasing FEC adaptability through fine tracking channel status, we found that recovery ratio
became higher even though the throughput overhead got smaller than other codes. Our 5G trace
driven experiments showed that even in highly volatile 5g situations, zero-retransmission is
possible in certain situations. It was also shown that using adaptive FEC was effective to bound
the end-to-end delay in both static and dynamic situations.
2
Contents
I. Introduction ... 3
II. Background ... 5
2.1. Weakness of Automatic Repeat Request (ARQ) ... 5
2.2. Forward Error Correction packet recovery ... 6
2.3. Extensible QUIC ... 7
III. Observation ... 7
IV. System Design ... 9
V. Related Works ... 16
VI. Evaluation ... 17
VII. Conclusion ... 20
3
I. Introduction
Upcoming fourth industries demand low latency in many ways. One of them is the remote control industry combined with the 5G infrastructure, which already has a lot in place, including a doctor's remote surgery on patients overseas, or working remotely for the factory to work day and night alternatively. However, intercontinental remote control industries have a lot of safety concerns, so there is a particular need for stronger latency bound. Tasks such as remote surgery or remote heavy machine control can lead to serious accidents with only a few deadline violations.
Thus, to satisfy the low latency requirements of these industries today, various methods of low delay have been studied. There are many factors that cause latency in the network, such as transmission delay and propagation delay, but the queuing delay is cited as the major factor. Therefore, many current low- latency work also aims to keep queuing low and ensure low latencies of 99.0 to 99.9 percent packets[18, 19, 20, 21, 22, 23, 24]. There are several new works that help end-host to know the congestion of inner network well. However these latest low-latency methods also has weaknesses to be used in mentioned industries.
The problem with the low-latency techniques we just described is that they do not care about the latency of the 0.1% tail packets. For low delay techniques, packets with a 0.1% tail latency are mostly caused by network path error or loss. This is because existing low-latency techniques continue to use ARQ for reliability. ARQ is a method used by TCP to cope with packet loss, simply retransmit the packet when the packet loss is detected. However, this method is not appropriate if it is important to ensure deadline 100% because it requires additional delays such as RTO, 3duplicate ACK, and RTT- sensitive retransmission.
Neal Cardwell et al. compared of the tail latency between with and without retransmissions, according to each RTT. They showed that the tail latency can be up to 10x longer by additional retransmission, RTOs in [11]. So to prevent further delays due to this retransmission, many researchers have been working on FEC that can recover packet loss in half RTT without retransmission,
FEC is basically a method of protecting traffic from loss, by encoding packets to send from lossy channels and adding redundancy for repair. Many XOR, Block, or sliding window code based packet level FEC were studies before, but they couldn't overcome the basic limitations of their code due to poor adaptiveness
In order to achieve higher FEC performance on state-varying channels, we thought near real time level adaptability was essential, so designed a method to learn future loss pattern on deep learning model
4
to determine FEC parameters. We propose ZeroR, a channel prediction based FEC framework protecting network deadline from performance degradations by packet retransmission.
Our evaluation results show that zero-retransmission is possible even in highly volatile 5g channel on certain situations. It was also shown that using adaptive FEC was effective to bound the end-to-end delay in both static and dynamic situations.
Figure 1: Key idea of ZeroR framework.
Therefore, our work’s contribution is as below.
It’s the first technology to control FEC parameters by tracking varying channel losses in advance at near-real time. Proposed FEC technique satisfies high recovery rate, low throughput overhead, and low delay overhead simultaneously.
On top of that, I measured and analyzed the loss pattern of the domestic 5g channel to predict future loss. Experiments figured that 0% retransmission is possible in certain static situations, and FEC based transport has fewer deadline violations than cc-based low latency transports.
5
II. Background
In this section, we describe the basic works of Forward Error Correction(FEC) recovery and features of QUIC, UDP based user level transport protocol.
2.1. Weakness of Automatic Repeat Request (ARQ)
ARQ is Error control method based on retransmission for reliable data delivery on the communication line. ARQ can be divided into three representative types, ‘Stop and Wait’, ‘Go Back N’, and ‘Selective Repeat’. ‘Go back N’ is mostly used by TCP to cope with packet loss, retransmitting the packet when the packet loss is detected. However, this method is not appropriate if it is important to ensure deadline 100% because it requires additional delays such as RTO, 3duplicate ACK, and RTT-sensitive retransmission. Neal Cardwell et al. compared of the tail latency between with and without retransmissions, according to each RTT. They showed that the tail latency can be up to 10x longer by additional retransmission, RTOs.
Figure 2: Basic works of representative FEC codes, XOR, block, and sliding window codes.
6 2.2. Forward Error Correction packet recovery
So to prevent further delays due to this retransmission, many researchers have been working on FEC that can recover packet loss in half RTT without retransmission. FEC encodes the traffic payload, an additional repair packet is added to the system to detect errors as well as to correct errors First, the XOR code. There are four essential concepts in the FEC as below.
Source symbol: a symbol containing information from the original object.
Source block: a subset of the object that is composed of k source symbols that are processed together by the FEC code.
Encoding symbol: an encoded symbol is a symbol produced by the FEC code.
Repair symbol: a symbol containing information generated by the FEC code which can be used to recover erased (lost) source symbols.
Near optimal code allows losing as much as the redundancy in the source block. Typical FEC codes can be divided into three categories:
Figure 2 shows the basic works of representative FEC codes, XOR, block, and sliding window codes.
The XOR code use XOR-based algorithm to generate redundancy, which is very simple and fast to encode and decode. However, it can create only one repair packet within a source block so it cannot recover multiple loss occurs in that block.
Second is the block code. Block code complements the shortcomings of XOR code that cannot recover multiple loss. However, since the values of source block size K and encoding block size N are fixed, it is very likely that user can experience unnecessary in-order delay or throughput overhead when the channel environment gets better
The third is the sliding window code. Sliding window code is a method of overlapping encoding by sliding windows according to parameters, developed to mitigate the long in-order delay experienced by the block code.
So many XOR[3,6, 15], Block[7, 12, 13], or sliding window code[1, 4, 16] based FEC were studies before, but they couldn't overcome the basic limitations of their code due to poor adaptiveness.
7 2.3. Extensible QUIC
QUIC’s extensibility makes it easier to apply packet level FEC at the application level. First developed by Google, QUIC is a UDP-based user-level transport developed to replace TCP's inefficient behavior.
There are various functions such as fast connection, multiplex connection options, assignment of unique sequence numbers, and authentication and encryption. It is implemented at the user level, so unlike TCP implemented within the kernel, it is easy to implement 3rd party plugins or modify multiple functions.
Google also used the FEC function in its early QUIC version, but was deprecated due to its effectiveness.
Recent researchers have currently come up with experimental attempts to implement various functions such as packet-level FEC in QUIC.
III. Observation
QUIC’s Based on it, I first tested FEC on the fixed-Reed Solomon block code in the local environment to see if it's really useful to apply it at the application level. First, I used RS codes that fixed K and N at 30, 45 respectively to keep the overhead of encoding decoding time small. This FEC delay was compared to existing TCP, changing the loss rate from 0 to 10% in a lost environment. As shown in figure 3, the encoding decoding time of the FEC block was extended proportionally to the block size.
Moreover figure 4 demonstrates that TCP has an advantage in terms of average delay when the loss rate is less than 1%. since TCP has a significant increase in delay due to retransmissions when the loss rate rises above 1%, FEC-based error recovery operations have been found to have significant advantages in terms of average or tail delay.
8
Figure 3: Reed-Solomon code encoding and decoding time for (K, N) = (30, 45)
So there are several requirements for good packet level FEC. Recovery ratio must be high for tail problem management. It must be able to respond to all different types of losses, such as single isolated, correlated, burst loss. At the same time, FEC throughput overhead must be as small as possible It must have adaptable behavior while responding to all different loss types for maximum recovery with minimal overhead. Lastly, FEC delay must be minimized. For block codes, in-order delay and encoding/decoding time itself must be minimized. Proactive behavior is better than reactive one.
Reactive adaptation will result in retransmissions during that time when the loss pattern changes, so this retransmission must be prevented in advance.
9
Figure 4: Delay comparison between TCP and packet level FEC.
IV. System Design
Based on observations, we developed ZeroR design to satisfy both low throughput overhead and high recovery ratio on varying channel. In order to achieve higher FEC performance on 5G channels, near real time level adaptability was essential, so designed a method to learn future loss pattern based on deep learning model to determine FEC parameters. There are three major design ideas related to the key idea.
The first idea of design is for efficient adaptive block code. Most codecs do not know the channel's variability, so the FEC parameters are set and not changed. In order to predict channels with Near Real time and reflect them in FEC behavior, FEC parameter sinks between end hosts must be synchronized in real time. To do this, we added a header for FEC parameter update size 4B that can deliver type of code, block ID, K, N, etc. to the front of the payload like figure 5.
Figure 5: Header design to transfer FEC meta data.
And the second is to choose the code that matches the adaptive FEC. The LDPC code is a block code and has several characteristics that allow adaptability to demonstrate optimized FEC behavior as shown in figure 6.
At first, LDPC is a small rate code. Small rate code allows to generate near infinite redundancies even if the source block size is small, so if we predict the loss well, we can recover large losses with a small in-order delay. Next, LDPC has systematic property. Systematic code is the code that retains the same source packets after encoding. This property allows the source packets to be sent first during encoding, so the receiver decode early. Under these actions, encoding delays could be eliminated when loss does not occur with such common case optimization.
10
adjusting CPU frequency or memory bandwidth are different in two blocks. The solid line indicates
Figure 6: Benefits of LDPC based codec design
The second key idea of my design is to predict future channel loss through deep learning and to find the most targeted location in FEC redundancy and recovery ratio tradeoff. we aim zero retransmission, so we focus on finding the smallest redundancy while achieving 100% recovery ratio.
Therefore we observed the loss patterns of SKT domestic 5G channel. Static and dynamic
environments were observed separately, while Static environment was standing outside condition in Seoul National University, and dynamic environment was observed on a moving subway. BBR is used for congestion control algorithm.
As you can see in figure 7, there's a difference between static and dynamic traffic. The Inflight packet shows that the transmission volume in the static channel is greater than in the Dynamic channel. Also, the loss pattern can be divided into three types as observed. The first type is steady mild losses less than 5. Steady mild losses were observed in both static and dynamic environment throughout the whole traffic. We estimate that SKT's 5G conservatively bound the maximum number of
retransmissions of HARQ between base stations and mobile devices, resulting in such a small continuous loss. The second type is the sporadic burst loss of less than 500. It was observed both static and dynamic environment. And finally, there are more than 1,000 heavy burst loss. This was observed on the dynamic channel, where the collected PCI information observed a change in PCI
11
value each time and confirmed that it was due to Handover by mobility.
Figure 7: measured loss pattern of 5G
The estimated reasons for the above three types of loss are as follows. Given that the first steady-mild loss type occurs with isolated pattern less than five, and occurs more frequently in dynamic than static, it is assumed to be caused by a wireless error that HARQ failed to recover.
Burst loss, less than the second 500, is estimated to be due to buffer overflows, given that it occurs at hundreds of levels of correlated[2] and is better observed in high-transmission static.
The last heavy burst loss is observed to block the channel for a certain period of time, due to the PCI transition.
Therefore, the loss of type 1 and type 2 will be recovered by giving the correct redundancy through adaptive FEC. For the 3 type, it is impossible to restore to FEC because the channel is blocked and the packet cannot be sent for a certain period of time, and instead we propose a pending algorithm.
12
This solution requires good prediction of the amount of future loss. To predict the above observed loss patterns, we needed to know the relationship between these loss patterns and network information. We used TCP probe and Android API to collect various traffic information and cell information to understand the relationship with the 5G loss observed.
I failed to recognize meaningful correlation between data and only the weak correlation with future loss and single RSRP was observed. Therefore, I used deep learning model-based black box to learn some features that human hardly see. Among deep learning models, LSTM has a memory cell, which has benefits to learn sequential information that continues from the past like figure 8. Input values, such as throughput, round trip time, RSRP, and current losses accumulated from the past 1000 ms, are used as learning and inference data for future loss prediction.
Figure 8: LSTM input data for loss prediction.
However, the thing to be careful about, it is not appropriate to use cell info collected by mobile devices directly without any processing by the server-side sender for downlink situations. For example, in a downlink situation, if the server side sender receives the cell information measured from the mobile device and starts a learning or inference immediately, that cell information is as far behind half RTT due to a transfer time. Furthermore, if the monitored information is used to predict the loss of the radio side, additional half RTT, FEC encoding, and inference time are required to reach the wireless network where the loss occurs. Therefore, the server side sender must predict future loss by that time, and we decided to predict the maximum loss of the future (1RTT + inference time + encoding time, 1RTT +
13 2*inference time + encoding time) time section.
Figure 9 is the result of loss prediction on static channels. The predicted loss was conservatively set for 100% recovery. FEC parameters are basicalyy set as K = 50, N = K + 6, and R = 6 to recover mild loss. In this state, when the sender predict burst loss, change the parameters in a way that K = CWND - P_L, N = CWND, R = P_L. This set showed the average 10% throughput overhead of the mild and an average of 80% throughput overhead for burst loss observed.
Figure 10 is dynamic loss prediction result. For loss in the Dynamic environment, type 1 and type 2 losses could be recovered in the same way as in the static environment. However, in the case of a heavy burst loss, there is a time the channel is completely blocked by HO, so FEC is not effective. So I propose a pending-based algorithm since to keep sending packets to blocked channels is inefficient.
Figure 9: Loss prediction for static 5G environment
14 Figure 10: Loss prediction for dynamic 5G environment.
In a blocked channel, continual sending method has a big weakness. If the channel is blocked, the sender must decide to retransmit after RTO, since 3 duplicated ACK or NACK cannot reach the sender.
In TCP, the RTO value is default for at least 3 seconds and a minimum of 1 second, so the user must experience a delay of at least RTO for each heavy burst loss like figure 11. Therefore, rather than this, it is advantageous in terms of response times to hold packets at the moment the channel is blocked and send them as soon as the channel is released. This approach can bypass additional RTOs or unnecessary cell interferences.
15 Figure 11: The RTO problem of channel blocking.
However, it is very important to predict the start and end time of the channel block accurately when using pending.
For example, if the channel is not blocked yet, pending in advance wastes throughput during that time, and the same is true for predicting the end time lately. Because the loss prediction by LSTM is conservatively predicted, we predict start timing an average of 114 ms in advance.
To more accurately predict the timing of this giving, cell info is utilized. First, keep monitor cell info in every 1 ms.
There are eight different types of handover events defined in LTE: A1–A6, B1 and B2. By the NSA structure of 5G, the data plane of the 5G service channel is separated from the infrastructure of the LTE service, but the control plane of 5G is controlled by the LTE master eNB in the event of a handover in 5G. This means that the handover of 5G is similar to LTE, so the handover trigger-decision algorithm in LTE is still available. As shown in figure 12, a variant of the existing LTE power budget handover algorithm [17] is used to predict the start time prediction. When burst loss is predicted, the collected cell info determines that if the RSRP of the neighboring cell is more than 3 decibels larger than the RSRP of the serving cell for more than 290ms, the sender's packet transmission is stopped immediately before it occurs. It can reduce the start time error into about 10ms.
The real ending timing of handover can be detected simply by PCI transition time.
16
Figure 12: Pending algorithm accuracy calibration method.
V. Related Works
Application level FEC
Many coding techniques, such as XOR, block, rateless (e.g. Raptor code[26]), and convolutional code[8], have been studied to prevent additional delays caused by ARQ.However, the majority of code is insensitive to channel changes, or only works in a reactive manner to channel feedback.
In the case of XOR code, encoding decoding time is fast and implementation is simple, making it easy to use for real applications, but there is a fatal disadvantage of being unresponsive to multiple loss[28, 29].
For fixed block code, multiple loss that XOR code cannot solve can be recovered, but there is an in- order delay problem for encoding/decoding, and if adaptation to channel is not done, the FEC overhead is too large or the recovery ratio drops.
The fountain code is theoretically capable of generating and sending infinite repair packets until the receiver completes decoding, enabling some degree of adaptive redundancy adjustment. However, the limitations are that the encoding must continue until the receiver receives the ACK to know when to complete decoding, and that the delay overhead is large if the encoding decoding time is not adjusted properly because of the data size[32,33,34].
17
The convolutional code can have the same recovery performance while reducing in-order delay compared to block codes, as it encodes with only the current data, but experiences more encoding/decoding times and delays due to nested encoding[30, 31].
To address these fundamental problems above, several FEC techniques have proposed their feedback methods and solutions to adapt to the changes of a channel state. For example, by monitoring the reactive feedback of the channel, [13, 15] attempted to minimize additional delays and three group overhead by reducing the amount of repair packets in the block code. [26, 27] conducted a study in which convolutional codes have good recovery rates for both single isolate loss and burst loss, while minimizing FEC overhead. Despite these efforts, however, none of them devised a way to predict the channel's state changes in advance and perform optimized actions, and for highly volatile channels, no sophisticated tracking of channel states is possible.
Finally, we will show the effectiveness of our design in Section 6 by comparing other FEC technique with these weak adaptability on QUIC based complete transports, pQUIC[1] and rQUIC[3] designs in terms of FEC overhead and recovery ratio. In addition, we will analyze what delay-throughput tradeoff adaptive FEC has through comparison with other ARQ-based transport.
VI. Evaluation
First of all, our experiment was conducted as trace-driven simulation on actual data from SKT 5G downlink channel in Korea. Our domestic 5G measurement involves two 5G phone models, Samsung Galaxy S20 and Galaxy Note 10. Both the S20 and the S Note 10 support 5g channel communication, each with a Qualcomm SM8250 Snapdragon 865 chipset and a Qualcomm SM8150 Snapdragon 855 chipset.
Since our adaptive FEC design uses network traffic info and cell info simultaneously, we measured four types of information, such as throughput, RTT, using TCP probes, and cell info, such as RSRP, using the Android API. The end hosts for traffic generation used iperf3's clients and servers, fully saturated 5G downlink channels and monitored above performance indicators for 70 seconds.
We used a variety of open source codecs, including the Reed-Solomon code and the LDPC-staircase code provided by OpenFEC(http://openfec.org/), for testing adaptive FEC. To test our design, we have used our own trace-driven python script simulation. We initially wanted to replay the trace using MIT MahiMahi, but it was unable to utilize the loss information, so tested the simulation by own testbed directly reflecting timings of throughput and losses in real trace.
18
Several experiments have been performed to estimate the goodput and delay performances of our design and assess advantages of adaptive FEC in the 5G saturated channel with BBR congestion control. We compared the state-of-the-art packet-level FEC transports and their FEC efficiency on top of the 5g static BBR trace.
In pQUIC implemented efficient sliding window FEC and rQUIC represents adaptive behavior by adjusting block ratio of XOR code through statistical residual loss.
As observed in figure 13, we can see that the overhead by my ZeroR is about 13% in average, so it has much less throughput overhead compared to other FECs. However, we still achieve 100% recovery ratio through predictive-based adaptability.
(a) Throughput overhead comparison (b) Recovery ratio comparison Figure 13: Throughput and recovery ratio comparison
Next, I observed delays of the existing ARQ-based BBR transport and FEC-based BBR in static and dynamic environment.
In the case of Static, both mild loss and burst loss was recovered by FEC, so reduce tail latencies and deadline violations. However, the average response time was increased due to the encoding and decoding time. In the case of Dynamic environment, the overall improvement to the delay was made through FEC and pending, rather reducing the mean response time. The number of violations over 1000 has also been significantly reduced. All these results can be observed in figure 14, 15, 16.
19
(a) BBR (b) ZeroR Figure 14: Response time comparison between BBR and ZeroR in static channel
(a) BBR (b) ZeroR
Figure 15: Response time comparison between BBR and ZeroR in dynamic channel
(a) Static (b) static (c) dynamic Figure 16: Latency deadline violation comparison
20
VII. Conclusion
In this work, we proposed ZeroR, a channel prediction based FEC framework protecting network deadline from performance degradations by packet retransmission. We evaluated the efficiency of adaptive FEC with fine tracking channel status, and concluded that it can reduce the number of deadline violations and delay boundary. It also showed that zero-retransmission is possible in certain situations even on state varying 5G channel.
21 REFERENCES
1.
Quentin De Coninck, François Michel, Maxime Piraux, Florentin Rochet, Thomas Given-Wilson, Axel Legay, Olivier Pereira, and Olivier Bonaventure. Pluginizing quic. In SIGCOMM 20192.
Dongzhu Xu, Anfu Zhou, Xinyu Zhang, Guixian Wang, Xi Liu, Congkai An, Understanding Operational 5G: A First Measurement Study on Its Coverage, Performance and Energy Consumption In SIGCOMM 20203.
P. Garrido, I. Sánchez, S. Ferlin, R. Agüero, and O. Alay, “rQUIC: Integrating FEC with QUIC for robust wireless communications,” in Proc. IEEE Global Commun. Conf. (GLOBECOM) 20194.
François Michel, Quentin De Coninck, and Olivier Bonaventure. 2019. QUICFEC: Bringing the benefits of Forward Erasure Correction to QUIC. IFIP Networking 20195.
J. Cloud, D. Leith, and M. Medard, “A coded generalization of selective ´ repeat arq,” in INFOCOM 20156.
I. Swett, “Quic-fec,” https://datatracker.ietf.org/meeting/99/materials/ slides-99-nwcrg-08-swett- quic-fec-00, 2017, accessed: 2018-06-027.
Rula et al., “Mile high wifi: A first look at in-flight internet connectivity,” in 2018 World Wide Web Conference on World Wide Web8.
T. Ho, M. Medard, R. Koetter, D. R. Karger, M. Effros, J. Shi, and ´ B. Leong, “A random linear network coding approach to multicast,” IEEE Trans. Inf. Theory, vol. 52, no. 10, pp. 4413–4430, 2006.9.
M. Karzand and D. J. Leith, “Low delay random linear coding over a stream,” in Proc., IEEE Allerton Conf. Commun., Control, and Computing, Sep. 2014, pp. 521–52810.
“Adaptive causal ´ network coding with feedback,” IEEE Transactions on Communications, vol.68, no. 7, pp. 4325–4341, 2020.
11.
Tail Loss Probe (TLP) Converting RTOs to fast recoveries draft-dukkipati-tcpm-tcp-loss-probe-00 Nandita Dukkipati, Neal Cardwell, Yuchung Cheng, Matt Mathis12.
S. Holmer, M. Shemer, and M. Paniconi. 2013. “Handling packet loss in WebRTC”. In Proc. IEEE Intl. Conference on Image Process13.
M. Nagy, V. Singh, J. Ott, and L. Eggert. 2014. Congestion control using FEC for conversational multimedia communication. In Proc. the 5th ACM Multimedia Systems Conference14.
“Tiny codes for guaranteeable delay,” IEEE J. Sel. Areas Commun., vol. 37, no. 4, pp. 809–825, Apr. 2019.22
15.
HANDLING PACKET LOSS IN WEBRTC Stefan Holmer, Mikhal Shemer, Marco Paniconi Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA, USA16.
Low-Latency Network-Adaptive Error Control for Interactive Streaming MM ’19, October 21–25, 2019, Nice, France17.
Liao, Qi & Awan, Daniyal & Stanczak, Slawomir. (2016). Joint Optimization of Coverage, Capacity and Load Balancing in Self-Organizing Networks.18.
Zaki, Yasir, et al. "Adaptive congestion control for unpredictable cellular networks." Proceedings of the 2015 ACM Conference on Special Interest Group on Data Communication. 2015.19.
Cardwell, Neal, et al. "BBR: Congestion-based congestion control." Queue 14.5 (2016): 20-53.20.
Leong, Wai Kay, Zixiao Wang, and Ben Leong. "Tcp congestion control beyond bandwidth-delay product for mobile cellular networks." Proceedings of the 13th International Conference on emerging Networking EXperiments and Technologies. 2017.21.
Park, Shinik, et al. "Exll: an extremely low-latency congestion control for mobile cellular networks." Proceedings of the 14th International Conference on emerging Networking EXperiments and Technologies. 2018.22.
Arun, Venkat, and Hari Balakrishnan. "Copa: Practical delay-based congestion control for the internet." 15th {USENIX} Symposium on Networked Systems Design and Implementation ({NSDI}18). 2018.
23.
Jay, Nathan, et al. "A deep reinforcement learning perspective on internet congestion control." International Conference on Machine Learning. 2019.24.
Li, Yuliang, et al. "HPCC: High precision congestion control." Proceedings of the ACM Special Interest Group on Data Communication. 2019. 44-58.25.
A. Shokrollahi, “Raptor codes,” IEEE/ACM Transactions on Networking (TON), vol. 14, no. SI, pp. 2551–2567, 2006.26.
Optimal Streaming Codes for Channels With Burst and Arbitrary Erasures IEEE TRANSACTIONS ON INFORMATION THEORY, VOL. 65, NO. 7, JULY 201927.
Rate-Optimal Streaming Codes for Channels with Burst and Isolated Erasures 2018 IEEE International Symposium on Information Theory (ISIT)28.
Sasaki, Chikara, et al. "On unicast based recovery for multicast content distribution considering XOR-FEC." 2005 Asia-Pacific Conference on Communications. IEEE, 2005.29.
Langley, Adam, et al. "The quic transport protocol: Design and internet-scale deployment."Proceedings of the Conference of the ACM Special Interest Group on Data Communication. 2017.
23
