PRNC Protocol

PRNC protocol puts the PRNC algorithm into real network environment.

With the adaptive retransmission and batch mechanism mentioned above, our PRNC algorithm could be applied in UDP. The characteristic of linear network coding gives the advantages of data distribution and data mixing.

The flexibility of UDP packet formate helps us to construct the ideal packet regardless of the restrict in TCP packet formate. Therefore, in PRNC proto-col, we choose UDP as our development protocol. The following paragraph describe the PRNC protocol in detail.

System Architecture

The figure below depicts the architecture in one host. One host contains the batch mechanism, PRNC encode and PRNC decode. The host receive codec from other peers via batch mechanism and then use PRNC decode to recover the original data. If there are other peers wants these data, the host use PRNC encode to make codec and transmit to the peers via batch mechanism. Notice that, in the PRNC algorithm, there are two phase for decoding. The host do the first phase if the accumulated codec is larger than the watermark and do the second phase if the result of the first phase is zero, which means the codec is solvable.

Figure 3.14: The architecture for PRNC protocol

Notation Definition

To specify the detail in PRNC protocol, we have the following notation

de-• Batch: One batch contains number of segments. The size of the batch window can be presented as W .

• Segment: One segment represents one coding unit. The size of one segment is n.

• Codec: The codec is generated from the segment by using PRNC algo-rithm. The size of one codec is k.

• NEED: The NEED is the number of dependent equations when decod-ing.

• watermark: The watermark is the point to trigger the PRNC decoding and can be denoted as w.

• lost rate: The lost rate can be denoted as lt and can be calculated by NEED/RT T .

Packet Formate

The packet format for PRNC protocol are described here. There are two kind of UDP packets through the PRNC protocol. For the codec packet, besides the basic UDP header which includes source port, destination port, length and checksum, there are three header in this format: SegmentID, Timestamp and PRN. The SegmentID identify one packet’s segment. It is

very important that we do not use sequence number to identify every packet.

In TCP, it is necessary to identify every packet so that it can reconstruct the original data sequentially. In PRNC protocol, there is no need to record every packet. Instead, it records the segments. And the timestamp attribute is to provide adaptive retransmission. Finally, the PRN attribute is used for PRNC decoding. The last part in one codec packet is the coded data, which can be calculated by the PRNC encoding.

When the receiver get the codec, it would check the number of collected codec. If the codec in the same segment is larger than w, it would start PRNC decoding phase 2. When the segment is recovered or RTT is triggered, the receiver would send ACK back which indicates the NEED. The header of the ACK packet format are SegmentID, Timestamp and NEED. The two former attributes are the same with codec packet. The third attribute implies the number of dependent equations and request for more codec.

State Transition diagram

To illustrate how the PRNC protocol works in one host, there are two state transition diagram for both sender and receiver. In the first diagram, sender initial the batch window and set the next batch. Then we do PRNC encode for all segments in the batch window. There are W × n codec generated at

Figure 3.15: The packet formate in PRNC protocol

After sending out segments, the sender start waiting ACK. If the ACK arrives with NEED = 0, the sender starts preparing the next batch (the batch window size increased by one). But if the ACK arrives with NEED 6= 0, the sender will prepare NEED number of codec to retransmit and wait for the ACK again. If the ACK does not arrive in RTO, we assume the whole codec were missing. In such situation, the sender will prepare W × n codec and send again. The overhead is great when the timeout trigger. Therefore, the adaptive retransmission is very important and we don’t increase the batch window dramatically.

At the side of receiver, first we have to initialize the batch table and set the expect batch window. The packets with different SegmentID would be ignored when arrived. When the first expected packet arrive, the receiver start counting time. If the time is larger than RTO, the ACK with NEED =

Figure 3.16: State transition diagram of the sender in PRNC protocol

n for the segment would be send back. If the number of packets is larger than watermark w, the receiver start doing PRNC decode phase 1. After row reduce, we could check the codec dependency. If the codec in one segment are determined independent, the receiver could do PRNC decode phase 2 and then send ACK back with NEED = 0. But if there are no sufficient codec or codec dependency is found, the receiver would send ACK back with NEED = Numberof Dependency. Then go back the stage Receive Packets waiting for additional codec.

Figure 3.17: State transition diagram of the receiver in PRNC protocol

3.3.3 Performance Analysis

In order to know how practical our protocol is, we implement a file transfer program which is build with PRNC protocol. This program is written in C. Our test environment is in WLAN. We compare the performance with FTP and UFTP. The download time and throughput are recorded in dif-ferent file size with size from 100KB to 10MB. According to the result, we found the PRNC protocol has much more performance compare with UFTP and is nearly equals to the FTP. Although network coding mechanism has

some overhead such as computing time, but the transmission time is still the bottleneck. Our batch mechanism could save the times of transmission ACK, since one ACK message is send to acknowledge one segment of pack-ets. Compare to the FTP, the PRNC has better performance in transmitting larger file. The larger file is transmitted, the more packets may be lost. It implies that our PRNC protocol could sustain unreliable environment.

Figure 3.18: Download time comparison for PRNC protocol, pure FTP and UFTP

Figure 3.19: Throughput comparison for PRNC protocol, pure FTP and UFTP

Chapter 4 Conclusion

We proposed the novel idea in network coding and develop PRNC protocol.

The PRNC protocol provide better performance compare to the traditional file transfer protocol and also provides security. And it could not only applied in end-to-end file transfer but also peer-to-peer network. We believe that the benefits would be more when it is used in peer-to-peer network. In the future work, we could implement peer-to-peer applications using PRNC protocol and analysis the performance compare to the one without PRNC protocol.

These issue are left for anyone interested in.

Bibliography

[1] H. Liu, X. Tu, and J. Xie, “Network coding for p2p live media stream-ing,” in Network and Parallel Computing, 2008. NPC 2008. IFIP Inter-national Conference on, Oct. 2008, pp. 392–398.

[2] R. Koetter and M. Medard, “Beyond routing: an algebraic approach to network coding,” in INFOCOM 2002. Twenty-First Annual Joint Conference of the IEEE Computer and Communications Societies. Pro-ceedings. IEEE, vol. 1, 2002, pp. 122–130 vol.1.

[3] S.-Y. Li, R. Yeung, and N. Cai, “Linear network coding,” Information Theory, IEEE Transactions on, vol. 49, no. 2, pp. 371–381, Feb. 2003.

[4] T. Ho, R. Koetter, M. Medard, D. Karger, and M. Effros, “The benefits of coding over routing in a randomized setting,” in Information Theory, 2003. Proceedings. IEEE International Symposium on, June-4 July 2003, pp. 442–.

[5] C. Gkantsidis and P. Rodriguez, “Network coding for large scale con-tent distribution,” in INFOCOM 2005. 24th Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings IEEE, vol. 4, March 2005, pp. 2235–2245 vol. 4.

[6] P. Chou, Y. Wu, and K. Jain, “Practical network coding,” in Proceedings of the 41st Allerton Conference on Communication, Control, and Computing, September 2003. [Online]. Available:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.11.697

[7] J. MacLaren Walsh and S. Weber, “A concatenated network coding scheme for multimedia transmission,” in Network Coding, Theory and Applications, 2008. NetCod 2008. Fourth Workshop on, Jan. 2008, pp.

1–6.

[8] D. Nguyen, T. Tran, T. Nguyen, and B. Bose, “Hybrid arq-random network coding for wireless media streaming,” in Communications and Electronics, 2008. ICCE 2008. Second International Conference on, June 2008, pp. 115–120.

[9] A. Albanese, J. Blomer, J. Edmonds, M. Luby, and M. Sudan, “Priority encoding transmission,” Information Theory, IEEE Transactions on, vol. 42, no. 6, pp. 1737–1744, Nov 1996.

[10] H. Zeng, J. Huang, S. Tao, and W. Cheng, “A simulation study on net-work coding parameters in p2p content distribution system,” in Com-munications and Networking in China, 2008. ChinaCom 2008. Third International Conference on, Aug. 2008, pp. 197–201.

[11] R. Bruno, M. Conti, and E. Gregori, “Throughput analysis and mea-surements in ieee 802.11 wlans with tcp and udp traffic flows,” Mobile Computing, IEEE Transactions on, vol. 7, no. 2, pp. 171–186, Feb. 2008.

[12] M. Wang and B. Li, “Lava: A reality check of network coding in peer-to-peer live streaming,” in INFOCOM 2007. 26th IEEE International Conference on Computer Communications. IEEE, May 2007, pp. 1082–

1090.

[13] J. Sundararajan, D. Shah, M. Medard, M. Mitzenmacher, and J. Barros,

“Network coding meets tcp,” in INFOCOM 2009, IEEE, April 2009, pp.

280–288.

[14] D. Niu and B. Li, “On the resilience-complexity tradeoff of network coding in dynamic p2p networks,” in Quality of Service, 2007 Fifteenth IEEE International Workshop on, June 2007, pp. 38–46.