# Adaptive Multi-Path Routing Protocol in Autonomous Vehicular Networks
## 3 Motivation
### Payload Size Determines Optimal Path  
The effective throughput of the wireless links is much lower compared to the physical link rates. For example, when we send a 1500-byte data packet on an 11 Mbps link, the maximum effective throughput would be somewhat close to 5 Mbps. The major cause of this phenomenon is the fixed PHY/MAC overheads, including PHY preamble and header, MAC header, RTS/CTS/ACK frames, DIFS/SIFS, backoff duration, and so on. We call these overheads \"fixed overheads\" since they are transmitted at a predetermined rate spending a fixed amount of medium time. Figure 2 shows the fixed PHY/MAC overheads independent of the selected transmission rate. The multi-rate-aware routing protocol proposed by [PERSON] et al. [26] uses medium-time as the routing metric. They calculate the medium time as the reciprocal of the effective throughput. One rough assumption is that the MAC payload is fixed at 1500 bytes. In real life, the packet size varies depending on the applications. According to the report from the Cooperative Association for Internet Data Analysis (CAIDA) [31], the actual Internet traffic is governed by small-sized packets of under 100 bytes comprising more than 50%. Most of these small-sized packets are TCP-ACK packets that are 40 bytes in length. Most of the large-sized packets, which are mostly TCP data packets, are about 550 bytes from TCP implementations that do not use path maximum transfer unit (MTU) discovery and 1500 bytes from those use it. Accordingly, fixing the MAC payload at a very high size, e.g., 1500 bytes, would be very unrealistic. Figure 1(a) shows the MAC medium time distribution when a 1500-byte payload (the same size as a TCP data packet when path MTU discovery is used) is transmitted, while Figure 1(b) shows the same distribution when a 40-byte payload (the same size as a TCP-ACK packet) is transmitted. For Figure 1(a), the medium time spent by the 1500-byte data payload usually dominates the total medium time. On the other hand, for Figure 1(b), the medium time spent by the PHY/MAC overhead occupies most of the medium time. What this means is that when a small-sized packet is transmitted, the data rate does not affect the throughput performance much. In fact, by selecting a high-data-rate link, the source nodes would tend to select a path that has a large number of hops, thus decreasing the overall throughput. Figure 3 shows a simple three-node topology, where node A is the source node and node C is the destination for constant bit-rate (CBR) traffic. When min-hop routing is used, source node A sends directly to node C, while node B is used as an intermediate hop when MTM is applied. Figure 3(a) compares the two metrics by the throughput performance for the topology using the ns-2 simulations as the application packet size is varied. The details of the simulation setup are presented in Section 6.1. It seems reasonable to use the MTM when large-sized packets are used, but a further glance at Figure 3(b) indicates that the min-hop metric is reasonable for small-sized packets. The threshold application packet size is about 140 bytes, which is 172 bytes (adding the UDP and IP header size) as a MAC  
payload. This also agrees with the actual Internet packet size distribution, where more than 50% of the IP packets are smaller than 100 bytes. This means that more that 50% of the packets may experience performance degradation by always using MTM as the routing metric. We will delve into this issue in Section 4.3. In essence, the optimal path that generates the maximum throughput would depend on the packet size. For small-sized packets, the min-hop metric is preferable, whereas the large-sized packets would show better performance by using MTM. At first glance, one may argue that the throughput increase by using min-hop metric instead of MTM for small-sized packets is not significant according to Figure 4b. Actually, the maximum application throughput increase by using min-hop instead of MTM is merely 33.8 kbps (4.2 KBps) when the packet size is 60 bytes.