Onion routing is a technique for building paths, or tunnels, through a series of peers, and then using that tunnel. Messages are repeatedly encrypted by the originator, and then decrypted by each hop. During the building phase, only the routing instructions for the next hop are exposed to each peer. During the operating phase, messages are passed through the tunnel, and the message and its routing instructions are only exposed to the endpoint of the tunnel.

This is similar to the way Mixmaster (see network comparisons) sends messages - taking a message, encrypting it to the recipient's public key, taking that encrypted message and encrypting it (along with instructions specifying the next hop), and then taking that resulting encrypted message and so on, until it has one layer of encryption per hop along the path.

In this sense, "garlic routing" as a general concept is identical to "onion routing". As implemented in I2P, of course, there are several differences from the implementation in Tor; see below. Even so, there are substantial similarities such that I2P benefits from a large amount of academic research on onion routing, Tor, and similar mixnets.

Bundling Multiple Messages
Michael Freedman defined "garlic routing" as an extension to onion routing, in which multiple messages are bundled together. He called each message a "bulb". All the messages, each with its own delivery instructions, are exposed at the endpoint. This allows the efficient bundling of an onion routing "reply block" with the original message.

This concept is implemented in I2P, as described below. Our term for garlic "bulbs" is "cloves". Any number of messages can be contained, instead of just a single message. This is a significant distinction from the onion routing implemented in Tor. However, it is only one of many major architectural differences between I2P and Tor; perhaps it is not, by itself, enough to justify a change in terminology.

Another difference from the method described by Freedman is that the path is unidirectional - there is no "turning point" as seen in onion routing or mixmaster reply blocks, which greatly simplifies the algorithm and allows for more flexible and reliable delivery.