# CoFi: Coding-Assisted File Distribution over a Wireless LAN
## 5 Performance and Evaluation
### CoFi Performance in an Elementary Topology  
Using the above trace-based simulation, we evaluated the performance of CoFi within the 3-node (AP, A, B) topology in Figure 3. Unless otherwise noted, all MAC/PHY layer parameter settings follow  
Figure 8: The packet loss rate traces for the 3-node (AP, A, B) topology in Figure 3. Each point represents the average packet loss rate during the past 5 s.  
Figure 7: Trace simulation: Feeding USRP packet loss traces into the ns-2 physical module (checked ns-2 packets are declared as losses). Our first performance metric is throughput, which is the amount of decodable data received by each client within the unit time. As demonstrated in Figure 9, the clients running CoFi experience much higher throughput than those using 802.11. CoFi provides more than three times improvement of time-averaged throughput for each client and guarantees a full link level reliability for each client. In contrast, the 802.11 MAC discards a packet if it cannot be acknowledged after a number of retransmission attempts (equal to Max Retry Limit). In addition, 802.11 suffers from link asymmetry. If the lossy link is on the forward direction, it affects 802.11 more than CoFi, because of the persistent retransmission and exponential backoff mechanisms. On the other hand, since CoFi uses batch transmission which requires fewer ACKs, it suffers less from ACK losses on the reverse direction. Figure 10 evaluates the time-averaged per-batch delay of CoFi and 802.11. For CoFi, the per-batch delay was measured without considering the packet reliability, i.e., it equaled each time duration when the receiver collected \(n\) different packets (\(n\) is the batch size). For 802.11, client A needed to strictly receive a packet one by one according to the order in which the packets were sent. At the same time, the \begin{table}
\begin{tabular}{c c} \hline \hline
**Parameter** & **Value** \\ \hline \hline Application & UDP with stable data source (data is always available \\  & for transmission) \\ CoFi block size & 1 KB \\ CoFi batch size & 8 \\ Data rate & 1 Mbps \\ Basic rate (for control packets) & 1 Mbps \\
802.11 Max Retry Limit & 7 \\ RX Thresh & \(1.52\times 10^{-11}\) \\ CS Thresh & \(3.08\times 10^{-11}\) \\ Transmission power & 0.2818 W \\ Path loss exponent & 4.0 \\ Shadowing deviation & 7.0 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Parameters setting for the performance test. Figure 9: The throughput (averaged over 10-s periods) of each client running 802.11 protocol and CoFi protocol in the elementary topology. transmitter needed to get full ACKs (equaling the number of packets). This indicated the probability that the data transmission was interfered by the changes of the channel environment being increased. Since the per-batch delay was inversely proportional to the throughput, the large performance gap between these two protocols was consistent with the throughput comparison in Figure 9.  
We proceed to evaluate the per-packet delay of both protocols. In CoFi an encoded packet is not visible at the receiver side until the entire batch it belongs to is decodable. Therefore, the per-packet delay of CoFi equals its per-batch delay if a packet reception fails during the hybrid coding stage. From Figure 11, we see that the per-packet delay of client A (which experiences low loss rate) when using CoFi is similar to the case when running 802.11. This is partly because of its hybrid coding scheme, which allows it to gracefully degrade to a non-coding protocol. In addition, since CoFi discards the persistent retransmission and exponential backoff scheme, the client B that is under a harsh channel condition does not affect the throughput of client A who experiences much less packet losses. For client B, the per-packet delay of CoFi is higher than that of 802.11, since the successful reception of an entire batch takes longer than receiving a single packet in 802.11. We noted that using a smaller batch size does not necessarily result in shorter delay, especially for lossy links.