802.3ad link aggregation

From wikipedia’s article on 802.3ad:

The most common way to balance the traffic is to use L3 hashes. These hashes are calculated when the first connection is established and then kept in the devices' memory for future use. This effectively limits the client bandwidth in an aggregate to its single member's maximum bandwidth per session. This is the main reason why 50/50 load balancing is almost never reached in real-life implementations, more like 70/30. More advanced distribution layer switches can employ an L4 hash, which will bring the balance closer to 50/50.
...
A limitation on link aggregation is that it would like to avoid reordering Ethernet frames. That goal is approximated by sending all frames associated with a particular session across the same link[3]. Depending on the traffic, this may not provide even distribution across the links in the trunk.

So, while 802.3ad does provide us redundancy, and the bandwidth of all connections to and from all hosts over a 802.3ad link will potentially aggregate to the combined bandwidth of the bonded interfaces, each individual client-server connection will be limited to the bandwidth available on a single component link of the bond.

It is arguable, then, that ALB (adaptive load balancing) may be a simpler and equally reliable method for bonding multiple interfaces on a server. In the case of ALB, no switch configuration is required, meaning that you can more readily swap ports on a switch.
…downside to ALB is that, because the server then presents one ip address with two different MAC addresses (one for each physical interface), when one interface loses connectivity, communication with any remote host that was using that physical interface will be lost until an ARP request causes the remote host to associate the IP address with the MAC of the remaining physical interface; some tcp sessions may timeout and fail entirely.

I am unclear as to whether gratuitous ARP is used to accelerate this failover.

I learned something new today.