[Banana] diff (banana load distribution, next-hop selection of multipath)

[Mingui Zhang <[e-mail]>]

Hi,

It seems worthwhile to sort out the differences between the next hop selection issue in the routing area and the banana load distribution issue. 

Next-hop selection for multipath has been a well-known issue in routing area. And, hash functions have been the well accepted technique to handle this issue [RFC4311] [RFC2991]. The essential thing is to "avoid the reordering that can result from transmission of different packets from the same flow over multiple different equal cost paths". These hashing functions are more applicable to routers used to route many flows. Banana targets home or enterprise users, one end of the connection (e.g., Home Gateway) locates at the edge of the network. Flows routed by the Home Gateway are very less. Hence, hash functions or even per-flow load distribution is not that effective. 

Next-hop selection makes no use of transportation information. As we discussed in the BOF, flow control and congestion control will be handled by banana. That means banana load distribution has to take some transportation information (throughput, latency, loss rate, buffer size, etc) into consideration. 

An advantage over the next-hop selection is that banana offers a small reordering buffer at the egress. For this reason, a certain level of packet disorder can be absorbed so that it does not screw up the TCP. With this buffer, banana can perform per-packet load distribution, which means packets from the same flow will be transmitted over multiple different paths.

Next-hop selection is mainly applicable to Equal Cost Multiple Paths. The multiple paths for banana do not have such limitation. 

For the scenarios that hosts perform the next-hop selection, some requirements are put on the host model [RFC4311] [RFC8028]. Banana does not intend to change the host model. All tricks are done in the box in front of the host (or firmware installed into the host).

Thanks,
Mingui