<figure><img src="image_1.png" /></figure>

HAL
open science

# Loss-Rate Driven Network Coding for Transmission Control

Chaoyuan Chiang, Yihjia Tsai

► To cite this version:

Chaoyuan Chiang, Yihjia Tsai. Loss-Rate Driven Network Coding for Transmission Control. 11th IFIP International Conference on Network and Parallel Computing (NPC), Sep 2014, Ilan, Taiwan. pp.49-60, 10.1007/978-3-662-44917-2_5. hal-01403064

HAL Id: hal-01403064

https://inria.hal.science/hal-01403064

Submitted on 25 Nov 2016

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Loss-rate Driven Network Coding for Transmission Control

Chaoyuan Chiang¹ and Yihjia Tsai²

¹ cory.scorpio@gmail.com

² eplusplus@gmail.com

Dept. of Computer Science and Information Engineering, Tamkang University
No. 151, Yingzhuan Rd., Tamsui Dist., New Taipei City 251, Taiwan (R.O.C.)

**Abstract.** As the growth of network based applications and services, the amount of data transmissions on the network is much more than ever. Transmission control is an important part of the Internet or other computer networks today. Network coding can help to optimize the efficiency of data transmissions by generating the redundant data for error correction. In this paper, we proposed the loss-rate driven coding, LRC, for transmission control. The goal of proposed mechanism is to minimize the coding operations. As a result, the power consumption and computing resource requirement can be reduced. Moreover, the proposed mechanism is compatible with standard TCP and feasible to implement.

**Keywords:** linear network coding, transmission control, TCP

## 1 Introduction

The applications of Internet and other computer networks have become more and more popular recent years. As a result, the amount of data transmissions is growing fast. Transmission control is an important issue for Internet and other computer networks. There are some researches discussed about improving transmission control. We reviewed those works and proposed a new network coding based transmission control mechanism in this paper.

In the OSI model [12], transmission control implements in the transport layer, which is also an important part of Internet and other modern computer networks today. The Transmission Control Protocol, TCP, is one of the most popular transport layer protocols. TCP provides reliable communication for upper layer applications by the acknowledgment mechanism. With acknowledgment mechanism, TCP can detect the segment loss and sense the network condition. Once a segment loosed or timed-out, it represents the network congestion occurred. TCP would control the transmission rate by adjusting the congestion window size to avoid network congestion.

TCP was developed for wired networks at beginning. Wired networks are simple, if the segment loss became often, the network is in congestion. TCP
will reduce the transmission rate once congestion occurs. In the modern network scenario, more wireless links, more carrier types, more complicated and larger topologies, there are more reasons caused segment loss or time-out, such as interference, fading, or temporary fault in the intermediate network device. The retransmission and congestion window adjustment policy of TCP may decrease the efficiency of transmission. In other words, TCP cannot reach the optimal usage of network throughput in some situations. For this issue, there exist some researches using network coding to improve the usage of network throughput in TCP transmission.

Network coding was first proposed in 2000 [1], which provides solution for optimizing network throughput in wireless networks, such as [6]. The major idea is combining data by XOR operations in broadcasting networks to minimize the amount of transmissions. A branch of network coding is the linear network coding [11]. Linear network coding is often applied in guaranteeing the fairness of peer-to-peer content distribution [2] or generating redundant data for error-correction [16]. The most interesting part of linear network coding is that it can distribute a large content into $n$ pieces equally in logical. For peer-to-peer content distribution, each peer can get the original content by decoding the $n$ received coded pieces. Consider the transmission in lossy networks, if sender divides the data into blocks and transmit in linear coding continuously, receiver can decode and get the original data after receiving any $n$ blocks. The receiver doesn't have to care the order of blocks. The idea above can be applied in TCP with lossy networks. We discussed more about this below in related works.

However, coding takes system resources on the devices. The implementations of linear network coding applied the algebraic operations on Galois Field. The decoding procedure is more complicated than encoding procedure. Minimizing the coded data and reducing the decoding works will have better computing efficiency for the devices. In other words, that would be more friendly to embedded devices with limited system resources. In this paper, we proposed the idea of loss-rate driven coding. We designed a transmission control mechanism, which use network coding as redundancy. The amount of redundancy is related to the sensed loss-rare. In the second section, we reviewed the related works. Then, we proposed our loss-rate driven coding idea in third section, followed by the performance evaluation and conclusions.

# 2 Related Works

## 2.1 TCP Congestion control

The Transmission Control Protocol, TCP, was proposed in [5]. TCP is a widely-used transport layer protocol today. The TCP data unit called segment, the data from upper layer would be divided into segments and transmit. Since the bandwidth of network links and the buffer size of network devices are limited, the packet would be dropped if the data comes faster than the bandwidth of network link. Once packets have been dropped in the lower layer, the transport layer segments would be lost or broken. TCP introduced the acknowledgment
mechanism. Sender transmits the segment with sequence number and header checksum. Receiver checks the received segment. If the segment is received correctly, receiver sends an acknowledgement, ACK, to inform the sender. The ACK contains the sequence number of next segment receiver expected. If the segment is lost or incorrect, receiver will repeat the same ACK until received the expected segment correctly. Thus, the completeness of data can be guaranteed.

For higher bandwidth usage, TCP will try to transmit a group of segments continuously, known as congestion window. The amount of segments in the group called window size. The window size will be increased when there is no transmission timed-out or network congestion. TCP will repeat a congestion window until received next correct ACK. Once the transmission timed-out or congestion occurs, TCP will reduce the congestion window size, slow down the transmission rate, to make the segments transmitted correctly.

## 2.2 Selective ACK

In the TCP congestion window Go-Back-N mechanism, any segment loss or fault will make sender retransmit all the rest segments in the window, some segments will be transmitted more than once, which is not quietly efficiently. The selective ACK, SACK, specified in RFC2018 [10], which allows receiver to ask sender retransmit specified segments.

The SACK scheme solved the redundant retransmission problem. Receiver specified the SACK options in the header of ACK. But there still exist extra costs. Sender takes time and computing resources to process the SACK and retransmit the specified segments.

## 2.3 Network coding

Network coding can help to recover the lost segments. There exist some researches applying network coding for peer-to-peer content distribution, such as [2]. The most interesting part of network coding in this field is that data can be uniformly divided into some pieces in logical. That is, if the original divided into $n$ blocks, any peer can decode and get the original data after collecting coded blocks. This characteristic also can be applied on error correction, such as [16].

The network coded TCP, TCP/NC, was proposed by Sundararajan et al, [13–15]. TCP/NC adds a coding layer between IP layer and TCP layer. The coding layer performance the linear network coding operations to encode or decode the segments. Kim et al, [8, 9], analyzed TCP/NC and concluded that TCP/NC may have better throughput and better efficiency in lossy networks. The drawback of TCP/NC is the transmission overhead. The segment header of TCP/NC is larger than standard TCP. So the performance of TCP/NC has lower than standard TCP when there is only a few segment loss. Later in 2013, Chan et al. [3] proposed the adaptive network coded TCP. They focus on adjusting the size of coding window according to the loss-rate. That is a quiet good idea, but there is no discussion about the segment header.
In this paper, we improved the efficiency of network coding based redundant mechanism in TCP. Our goal is to minimize the coding operations and get optimal performance. We discussed our idea, including the segment header in the next part below.

# 3 Loss-rate Driven Coding

The goal of this research is to minimize the coding operation and coded data. We named it as loss-rate driven coding, LRC. In the following, we use TCP/LRC denotes the proposed mechanism, which combined LRC and TCP. The basic idea LRC is sensing the segment loss rate and using coded segment as redundancy to recover the lost segments. Moreover, the proposed TCP/LRC is compatible with standard TCP. We described the details of our method in the following sub-sections.

## 3.1 Transmission model

The sender and receiver both maintain their own coding buffer. The coding buffer is a cyclic queue, called sender queue, $Q_S$, and receiver queue, $Q_R$, in sender side and receiver side, respectively. The data came from upper layer would be packed into segments in sender side. Then, the sender would transmit the segment and put a copy into sender queue, $Q_S$. After received the segment, receiver would put a copy into receiver queue, $Q_R$, and process the data in the segment for upper layer. For both of $Q_S$ and $Q_R$, the eldest segment is stored in the first element while the latest segment stored in the last element. In normal condition, $Q_S$ and $Q_R$ will rotate simultaneously with a little delay, like a tape, shown in Fig. 1.

When the network congestion, segment loss or fault occurs, $Q_S$ will rotate faster than $Q_R$. And some segments in $Q_R$ may not store in right order, shown as Fig. 2. This condition should be fixed. For $Q_R$, there should be at least one segment in right order. The segments stored in $Q_R$ with the right order are the candidates of coding head. Once sender detects the loss-rate greater than the threshold, sender will pause the processing of new data. Then encode the segments in $Q_S$ into coded segments and transmit. The first segment in $Q_S$ is the coding head. Receiver will receive the coded segments and put them into $Q_R$ until the first segment in $Q_R$ is coding head. That is, the segments stored in the first element of $Q_S$ and $Q_R$ have the same sequence number, shown as Fig. 3. Then, receiver can decode the coded segments in $Q_R$ and get the original data. Thus, $Q_S$ and $Q_R$ become synchronized again and the problem has been fixed.

Fig. 4 is the state diagram of proposed TCP/LRC mechanism. The transmission begins from the starting state, similar to the slow start procedure of standard TCP. The segments will be transmitted in minimal transmission rate, which will be increased each next round. When $Q_S$ is fully-filled, it switches to normal transmission state. Sender will detect segment loss in this state. Once the segment loss exceeded the threshold, it switches to the coding recovery state. In the coding recovery state, sender has paused processing new data, and start
<figure><img src="image_3.png" /><figcaption>**Fig. 1.** Both sender and receiver have a cyclic queue with same size, when transmitting under normal condition, the access pointers of two cyclic queue should rotate simultaneously</figcaption></figure>

<figure><img src="image_4.png" /><figcaption>**Fig. 2.** When segment loss or fault occurs, the access pointer rotation will incompatible, and there may have out-of-ordered segments is receiver's queue</figcaption></figure>

to send the linear combination of the segments in $Q_S$. Receiver collects the coded segments and performs the decoding procedure. After recovered the lost segments, it switches back to normal transmission state.

## 3.2 Sensing segment loss-rate

The ACK in standard TCP sends the sequence number of next expected segment. In TCP/LRC, the idea above also works, but with different meaning. Generally, the problem can be fixed by coding if the amount of lost segment is lower than the buffer size. As we discussed above, there should be at least one right-ordered segment in $Q_R$. But there may have segments not in the right order, which will push the right-ordered segments out of queue. For this condition, TCP/LRC should keep two indicators, the amount of right-ordered segments, $R_c$, and the amount of out-of-ordered segments, $R_g$.

Sender calculates $R_c$ and $R_g$ by the ACKs, and keep monitoring the two indicators. If $R_c$ is lower than the last segment of $Q_S$ or $R_g$ is greater than buffer size, the problem cannot be fixed by coding. Such situation should be avoided. If sender detected such situation is going to happen, it will pause processing new data and start sending coded segment.
<figure><img src="image_5.png" /><figcaption>**Fig. 3.** The amount of lost segments recovered by coded blocks, performing decode operations can get the original segments</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>**Fig. 4.** State diagram of proposed TCP/LRC mechanism</figcaption></figure>

## 3.3 Segment format

Considering the compatibility with standard TCP, we use typical TCP segment format. The header is briefly shown as Table [1]. There are nine bits for flags in the TCP header. The three reserved bits generally set to zero in standard TCP. For identification of LRC, we use one of them as flag. We labelled it as COD flag here, which will be used to identify TCP/LRC peer when setting up the connection. If the transmission is in coding recovery state, the COD flag will be set to identify the coding segment.

For the coding segment, we put the additional information in the URG pointer field for generating coding coefficients, which has an introduction in next section. URG mechanism is for urgent data in TCP. When the URG flag is set, it means the data need process quickly, and the URG pointer denotes the position of the urgent data. Thus, receiver can process the segment with higher priority. For the segment lost condition, the urgency is also expired. So here we use the URG point field to transfer additional information in TCP/LRC. When in normal transmission state, the urgent data mechanism is still available.

## 3.4 Encoding procedure

Linear network coding performs the algebraic operations in Galois Field. Some researches applied the random linear network coding, which will choose coding coefficients randomly. Random linear network coding can ensure that the linear
<table><caption>**Table 1.** TCP Segment Header</caption><thead><tr><th>Bit</th><th colspan="3">Fields</th><th>Bit</th></tr></thead><tbody><tr><td>0</td><td colspan="2">Source port</td><td>Destination port</td><td>31</td></tr><tr><td>32</td><td colspan="3">Sequence number</td><td>63</td></tr><tr><td>64</td><td colspan="3">Acknowledgment number</td><td>95</td></tr><tr><td>96</td><td>Data offset</td><td>Reserved</td><td>Flags</td><td>Window size</td><td>127</td></tr><tr><td>128</td><td colspan="3">Checksum</td><td>URG pointer</td><td>159</td></tr></tbody></table>

combination has a solution. But it will take bandwidth to transmit the coefficients to receivers. In TCP/LRC, we use a hash function, $H$, to generate the coding coefficients. With the hash function, we only need to put the hash seed in the header. We made TCP/LRC perform the coding operations in $GF(2^8)$. Many researches use $GF(2^8)$ because each number in $GF(2^8)$ is a byte. This makes it feasible for implementation.

When entered the coding recovery state, sender would pick a hash seed, $k$, for different coded segment. Then get the $n$ code coefficients for $n$ segments, as formula (1). And put the linear combination, $X$, in the payload of coded segment, as formula (2). The hash seed, $k$, will filled in the URG pointer field in the segment header. The sequence number of coding head, $D_1$, will be put in the sequence number field of coded segment. Thus, receiver can identify the coded segments as same group.

$$ \{C_1, C_2, \dots, C_n\} = H(k) \qquad (1) $$

$$ X = C_1 D_1 + C_2 D_2 + \dots + C_n D_n = \sum_{i=1}^{n} (C_i D_i) \qquad (2) $$

## 3.5 Decoding procedure

In linear network coding, $n$ coded segments can be decode and get the original data by the operations in formula (3). In LRC, we hope the amount of coded segments is minimized. When received a coded segment, receiver will unpack it in the buffer and determine whether it has the parts of the coded segment by the coding head number. If receiver already has the $u^{th}$ segment, part of the coded segment $X$, it will do the operation as formula (4) to remove the $u^{th}$ segment from the coded segment. $X'$ denotes the coded segment without the $u^{th}$ segment and $C_u$ denotes the coding coefficient of $X$. Because the addition operation in Galois field can be performed by XOR, adding $C_u D_u$ equals to remove it from $X$. The coding coefficients can be extracted from the hash function, $H$, with the hash seed in the URG pointer field of the segment header. Receiver also prepares a coding coefficient mask, $M$, once it received the coded block. The mask, $M$, is a binary array, or vector, with all zeros. When receiver find out it already has the $u^{th}$ segment, it will also set the $u^{th}$ bit of $M$ to one.
$$ \begin{bmatrix} D_1 \\ \vdots \\ D_n \end{bmatrix} = \begin{bmatrix} C_1^1 & \cdots & C_n^1 \\ \vdots & \ddots & \vdots \\ C_1^n & \cdots & C_n^n \end{bmatrix}^{-1} \times \begin{bmatrix} X_1 \\ \vdots \\ X_n \end{bmatrix} \quad (3) $$

$$ X' = X + C_u D_u \quad (4) $$

When there are $m$ zeros in $M$ and receiver has received $m$ coded segments with same coding head, receiver can decode and get the $m$ original segments. Receiver will re-order the coding coefficients, only use the $C_i$ with $M(i)$ is zero. And the size of coefficient matrix in formula (3) will be reduced. Then, receiver can do the decoding operations and get the $m$ original segments.

## 3.6 Congestion control

Although network coding can improve the throughput, there still has the bandwidth limit of network link. Transmit the segments too fast will cause network congestion. Standard TCP use the congestion window and ACK for congestion control. When transmitted an amount of segments, TCP will wait for the correct ACK before transmit other segments. TCP/NC adds a new layer between TCP layer and IP layer, so the congestion control is still handling by TCP.

In this paper, LRC also maintains the congestion window mechanism of TCP. After sender transmitted an amount of segments, it would wait for the ACK before continues. When entered the coding recovery state, the congestion window size will be reduced. We are studying for advanced in this issue, to adjust the transmission more accurate by $R_c$ and $R_g$. This may become our future work.

# 4 Performance Evaluation

## 4.1 Theoretical induction

The first indicator of performance is throughput, which denotes the amount of data can be transmitted per time period. For TCP without SACK, we assumed the average loss probability of each segment is $q$, and the mean value of window size is $w$. The $Z$ denotes the expected amount of actual transmitted segments, that is, considered the retransmitted or redundant segments. We calculate the usage of network link like formula (5). According to the Go-Back-N retransmission scheme of TCP, $Z$ will be the equation in formula (6). Our proposed mechanism can reduce $Z$ to $Z'$ shown in formula (7).

$$ \frac{\text{amount of original data}}{\text{expected amount of transmission}} = \frac{w}{Z} \quad (5) $$

$$ Z = w + \left( \frac{1+w}{2} \right) (1 - (1-q)^w) \quad (6) $$
$$Z' = w(1 + q) \qquad (7)$$

Comparing with TCP/NC, our mechanism has no transmission overhead because we use a hash function to generate the coding coefficients. The seed of hash function can be filled in the URG pointer of TCP header. The proposed mechanism does not need extra transmission for coded segments. Moreover, the proposed mechanism will perform coding operations only in necessary condition, the computing overhead and power consumption can be minimized.

For the computing complexity, according to formula (2), the complexity of encoding n segments is $O(n^2)$. This complexity level is similar to some searching and sorting algorithms. So encoding operation is acceptable for most of systems. The decoding operations in formula (3) have a complexity of $O(n^3)$. This is more complicated than most of other operations and is possible to solve by hardware decoding in the future. The proposed LRC mechanism minimized the coding operations, also minimized the extra costs of network coding.

## 4.2 Packet loss model

For the accuracy of simulation, we studied the packet loss model of real computer networks. The packet losses we discuss here are caused by wireless interference or fading, or sporadic fault in the network device, not caused by link failed or network device failed. Hohlfeld et al, [7, 4], analyzed the packet loss model by the Gilbert-Elliott Model in Fig. 5, which is inspired by Markov Model. Each of the network links is either in good (G) or bad (B) state. The probability of a correctly-transmitted bit in good state is $k$, while in bad state is $h$. On the other hand, the bit error rates in the two states are $1-k$ and $1-h$, respectively. In the good state, the probability of switching to bad state is $p$, staying in good state is $1-p$. In the bad state, the probability of switching to good state is $r$, staying in bad state is $1-r$. These works discussed the packet loss in networks including wireless network and mobile network. We used this model for the simulation network environment.

<figure><img src="image_7.png" /><figcaption>Fig. 5. The Gilber-Elliott Model defines the network link with two states, good (G) state and bad (B) state</figcaption></figure>
4.3 Simulation results

For simulation, we emulate the lossy network environment by the Gilbert-Elliot
Model. The probability from the good state to the bad state is 0.1, while the
probability from bad state to good state is 0.3. And the bit error rate in the good
state and bad state are 0.000001 and 0.000002 respectively. The content length
is 240,000 bytes while each segment carrying 1200 bytes. There are 200 original
segments in each round. We simulated 20 rounds, after each round, the bit error
rate in both good state and bad state increased 0.000003. We compared the
proposed mechanism, labeled as TCP/LRC here, with TCP/NC and TCP Reno.
Fig. 6 shows the relationship between dropped segments and actual transmitted
segments. As the growth of bit error rate, the amount of dropped segments also
increased after each round. TCP Reno detects segment loss by time-out or triple-
duplicated ACK and discarded the out-of-ordered segments, so the number of
actual transmitted segments was much more than the dropped segments plus
the original segments. TCP/NC and TCP/LRC transmit the linear combination
for the error recovery condition, so the number of actual transmitted segments
equal to the dropped segments plus the original segment.

<figure><img src="image_8.png" /><figcaption>**Fig. 6.** Comparison of the exact transmitted segments with the bit error rate increased after each round</figcaption></figure>

We also compared the total amount of transmitted data in transport layer, shown as Fig. 7. TCP/NC has additional information for network coding in the segment. As a result, TCP/NC has to transmit more data. Our TCP/LRC just uses the standard TCP header, so it will be more efficient when transmitting large content.

For the computing complexity, Fig. 8 showed that our TCP/LRC has less
coded segments than TCP/NC. The encoding and decoding procedure in TCP/LRC
is minimized. This let TCP/LRC can have lower power consumption and lower
computing resource requirement.
<figure><img src="image_9.png" /><figcaption>**Fig. 7.** Comparison of TCP/LRC and TCP/NC by the amount of transmitted data, in bytes</figcaption></figure>

<figure><img src="image_10.png" /><figcaption>**Fig. 8.** Comparison of TCP/LRC and TCP/NC by the amount of coded segments</figcaption></figure>

# 5 Conclusions

In this paper, we proposed the loss-rate driven coding, LRC. And combined LRC with TCP. With this mechanism, the amount of encoding operations and decoding operations can be minimized. The coded segment will be used only if needed. And the amount of decoding operations is also reduced to the actual required amount. Thus, this mechanism will be easier to implement in the embedded systems with limited system resources. We also used the standard TCP segment
header in the proposed mechanism. This can let the implement has higher compatibility with standard TCP. For the future works, we are studying about the congestion control issue. With a more accurate congestion control scheme, we hope the throughput could be optimized in the future.

## References

1. R. Ahlswede, N. Cai, S. Y. Li, R. W. Yeung: Network information flow, IEEE Transactions on Information Theory, 46, 1204–1216 (2000)

2. Gkantsidis, C. Rodriguez, P.R.: Network coding for large scale content distribution, 24th Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings IEEE (INFOCOM), vol. 4, 2235–2245 (2005)

3. Chan, Yi-Cheng, and Ya-Yi Hu: Adaptive Network Coding Scheme for TCP over Wireless Sensor Networks, International Journal of Computers, Communications and Control 8.6 (2013)

4. Gerhard Hasslinger, Oliver Hohlfeld: The Gilbert-Elliott Model for Packet Loss in Real Time Services on the Internet, Measuring, Modelling and Evaluation of Computer and Communication Systems (MMB), 14th GI/ITG Conference, 1–15 (2008)

5. J. Postel: RFC793, Transmission Control Protocol (1981)

6. S. Katti, H. Rahul, W. Hu, D. Katabi, M. Medard, and J. Crowcroft: XORs in the air: practical wireless network coding, IEEE/ACM Trans. Netw. 16: 3, 497–510 (2008)

7. Oliver Hohlfeld: Stochastic packet loss model to evaluate QoE impairments, PIK-Praxis der Informationsverarbeitung und Kommunikation, 32: 1, 53–56 (2009)

8. M. Kim, T. Klein, E. Soljanin, J. Barros, M. Medard: Modeling Network Coded TCP: Analysis of Throughput and Energy Cost, arXiv preprint arXiv:1208.3212 (2012)

9. M. Kim, M. Medard, and J. O. Barros: Modeling network coded TCP throughput: A simple model and its validation, Proceedings of the 5th International ICST Conference on Performance Evaluation Methodologies and Tools, 131–140 (2011)

10. Mathis, M. et al.: RFC 2018, Internet Engineering Task Force (IETF) (1996)

11. S. Y. Li, R. W. Yeung, N. Cai: Linear network coding, IEEE Transactions on Information Theory, 49, 371–381 (2003)

12. Stallings, William: Handbook of computer-communications standards, Vol. 1: the open systems interconnection (OSI) model and OSI-related standards, Macmillan Publishing Co., Inc. (1987)

13. J. K. Sundararajan, S. Jakubczak, M. Medard, M. Mitzenmacher, J. Barros: Interfacing network coding with TCP: an implementation, arXiv preprint arXiv:0908.1564 (2009)

14. J. K. Sundararajan, D. Shah, M. Medard, S. Jakubczak, M. Mitzenmacher, J. Barros: Network coding meets TCP: Theory and implementation, Proceedings of the IEEE, 99: 3, 490–512 (2011)

15. J. K. Sundararajan, D. Shah, M. Medard, M. Mitzenmacher, and J. Barros: Network coding meets TCP, IEEE INFOCOM, 280–288 (2009)

16. Zhen Zhang: Linear Network Error Correction Codes in Packet Networks, IEEE Transactions on Information Theory, 54, 209–218 (2008)