Rocket Leagues symmetric kickoffs, where both players on the same team are equidistant from the ball, pose an interesting communications challenge. The two players have to coordinate, via quickchat, which of them is going to go for the kickoff, and which is going to hang back, or collect boost, (or, in the case of Solo 3s, practice their turtle defense.) Each of them can write either “I’ve got it!” or “Take the shot!” If one player gets their chat in first, then the other player can decide to either accept the first’s tactical decision, or attempt to disagree by offering a counterproposal. This is perhaps not as interesting as the other possible case: both players issue their quickchats simultaneously. Often this causes confusion and gives the other team an advantage on the kickoff. As it turns out, this is a problem that has come up, and been solved, in what might be a surprising place: WiFi.

In the early days of computer networking, two computers could talk to each other by connecting some wires between them, and having each computer send messages by adjusting the voltage on the wire in ON-OFF patterns. This scheme is fairly straightforward, and is at the core of protocols like full duplex Ethernet.¹ We say that the set of wires being used is the physical medium over which the ethernet link is established.

Where things get interesting is when your medium is one which cannot be isolated. WiFi connections are made via radio waves in the wavelengths around 2.4GHz (or with 802.11n, possibly 5GHz). A particular channel will take up not only the frequency spectrum at its center, but also some of the frequencies around it. For this reason, it is difficult to have a dedicated transmission and receive frequency for each partner in each communication. There’s only a finite amount of bandwidth, and if you’re in a lecture hall of students with their laptops, there will be far more connections than there are WiFi spectrum channels to support them.

The solution to this problem is to have multiple devices talking on the same channel. As long as they take turns, they can all use the same bandwidth. The simplest possible scheme is to have each device simply transmit when they have something to send, and then throw away any messages which overlap with those sent by other devices. If two messages² overlap, even by a little bit, then they interfere with each other, and it is not possible to tell which parts have been interfered with and which have not, so both must be discarded in their entirety. As long as messages are sent infrequently enough that the chances of overlap are low, most messages will get through.

What do you do about the messages that do not? One option is to simply give up, and say that those messages are lost forever. Some networking protocols take this approach. Perhaps the most popular protocol to do so is UDP, although UDP is slightly higher up the networking stack than what we are describing. The idea behind this approach is that either the messages are time sensitive, and therefore worthless if they do not arrive soon after they are sent, or some mechanism above them detects that a message is missing and attempts to retransmit.

It would be nice to solve this problem here, instead of punting it up to someone above us, so we should attempt to retransmit a message if we detect that it has failed. Naively, we can try resending a message immediately after we detect that the channel is clear. Unfortunately, if both devices which were previously transmitting simultaneously are using this same scheme, they’ll both start transmitting again at the same time, when both of them realize that the other is done with the previous transmission. This will repeat — rendering the channel unusable — until one of the devices is turned off. In order to resolve this issue, we can implement something called a random falloff.

Random falloff is a strategy where when a device attempts to send a message, and the message is corrupted by another device trying to transmit at the same time, the first device waits for a random amount of time before attempting to retransmit. The hope is that the two devices will chose different random times to wait, and one of them will get their message in before the other is done waiting. Of course, it’s always possible that both will choose similar enough wait times, and get stuck again, but in this case each can again choose a random wait time, and keep going until their random sequences of waits desynchronize and one gets in before the other.

This works fine for two devices, but if a larger number of devices are simultaneously trying to use the same channel, it’s possible that the range of random falloff times is not great enough, and there is a high probability that multiple devices will choose the same time within the range. Concretely, imagine that there are 10 possible times to attempt to begin retransmission, and 11 devices simultaneously trying to transmit. By the Pigeonhole Principle³, at least one pair of messages will conflict. If this recurs, there needs to be a mechanism for increasing the range of wait times that each device can wait for. The typical falloff schedule used is to double the range of possible wait times each time a message is corrupted. This has a nice balance between growing rapidly, so after several rounds the probability of collision is very low, and keeping the wait times reasonable.

This protocol is called Aloha, after the first network to use it, appropriately named ALOHANet. ALOHANet was the first multi-device wireless packet network. It was developed at the University of Hawaii in 1971. The name stands for Additive Links On-line Hawaii Area, which was clearly chosen to fill in the acronym for the name they had already decided on. Although somewhat primitive, the ideas were refined into essentially the ones that are used in modern WiFi networks for bandwidth sharing, and your home router likely uses the same general ideas of random retransmission to let you use multiple devices at once.

This is also, to circle back to our original point, roughly the scheme which is used by Rocket League players on kickoffs. Each player will wait a random amount of time before sending a message indicating whether they’d like to take the kickoff or not. If both players signal their intentions at the same time, they will each choose some amount of time to wait before signaling a new intention. The trap that I have seen some players fall into is that they will always attempt to resignal as soon as the conflict is discovered. This makes some sense, because there is a limited amount of time before the kickoff happens, and both players must be in agreement before then. However, as you might recall, both players attempting to immediately resignal risks the same issues as in our shared medium network where both players (or devices) immediately resend and enter a loop of mangling each other’s messages.

Therefore, the best way to resolve this issue is to pick a random (or, as random as you can easily produce, given the circumstances) time between the current time and the time when the kickoff countdown hits zero to send your follow-up quickchat. I personally skew later, since a lot of people don’t realize the shared medium issue described above, and attempt to immediately correct the simultaneous quickchat. I typically pick a single time during a series of games and always resend right around then if there is a simultaneous quickchat, since it usually doesn’t happen more than once a game anyway. Adopting this Aloha protocol for rocket league kickoffs will reduce the amount of confusion when a simultaneous quickchat occurs, and does not run the risk of interacting badly with other people’s strategies, since from your perspective, everyone is picking a random time to resignal. Some just do it quicker than others.