=====================
Invisible Multihoming
=====================
Author: str4d
Created: 2017-05-22
Thread: http://zzz.i2p/topics/2335
Last updated: 2017-07-04
Status: Open
Overview
========
This proposal outlines a design for a protocol enabling an I2P client, service
or external balancer process to manage multiple routers transparently hosting a
single [Destination].
The proposal currently does not specify a concrete implementation. It could be
implemented as an extension to [I2CP], or as a new protocol.
Motivation
==========
Multihoming is where multiple routers are used to host the same Destination.
The current way to multihome with I2P is to run the same Destination on each
router independently; the router that gets used by clients at any particular
time is the last one to publish a [LeaseSet].
This is a hack and presumably won't work for large websites at scale. Say we had
100 multihoming routers each with 16 tunnels. That's 1600 LeaseSet publishes
every 10 minutes, or almost 3 per second. The floodfills would get overwhelmed
and throttles would kick in. And that's before we even mention the lookup
traffic.
[Prop123] solves this problem with a meta-LeaseSet, which lists the 100 real
LeaseSet hashes. A lookup becomes a two-stage process: first looking up the
meta-LeaseSet, and then one of the named LeaseSets. This is a good solution to
the lookup traffic issue, but on its own it creates a significant privacy leak:
It is possible to determine which multihoming routers are online by monitoring
the published meta-LeaseSet, because each real LeaseSet has corresponds to a
single router.
We need a way for an I2P client or service to spread a single Destination across
multiple routers, in a way that is indistinguishable to using a single router
(from the perspective of the LeaseSet itself).
Design
======
Definitions
-----------
User
The person or organisation wanting to multihome their Destination(s). A
single Destination is considered here without loss of generality (WLOG).
Client
The application or service running behind the Destination. It may be a
client-side, server-side, or peer-to-peer application; we refer to it as
a client in the sense that it connects to the I2P routers.
The client consists of three parts, which may all be in the same process
or may be split across processes or machines (in a multi-client setup):
Balancer
The part of the client that manages peer selection and tunnel
building. There is a single balancer at any one time, and it
communicates with all I2P routers. There may be failover balancers.
Frontend
The part of the client that can be operated in parallel. Each
frontend communicates with a single I2P router.
Backend
The part of the client that is shared between all frontends. It has
no direct communication with any I2P router.
Router
An I2P router run by the user that sits at the boundary between the I2P
network and the user's network (akin to an edge device in corporate
networks). It builds tunnels under the command of a balancer, and routes
packets for a client or frontend.
High-level overview
-------------------
Imagine the following desired configuration:
- A client application with one Destination.
- Four routers, each managing three inbound tunnels.
- All twelve tunnels should be published in a single LeaseSet.
Single-client
`````````````
-{ [Tunnel 1]===\
|-{ [Tunnel 2]====[Router 1]-----
|-{ [Tunnel 3]===/ \
| \
|-{ [Tunnel 4]===\ \
[Destination] |-{ [Tunnel 5]====[Router 2]----- \
\ |-{ [Tunnel 6]===/ \ \
[LeaseSet]--| [Client]
|-{ [Tunnel 7]===\ / /
|-{ [Tunnel 8]====[Router 3]----- /
|-{ [Tunnel 9]===/ /
| /
|-{ [Tunnel 10]==\ /
|-{ [Tunnel 11]===[Router 4]-----
-{ [Tunnel 12]==/
Multi-client
````````````
-{ [Tunnel 1]===\
|-{ [Tunnel 2]====[Router 1]---------[Frontend 1]
|-{ [Tunnel 3]===/ \ \
| \ \
|-{ [Tunnel 4]===\ \ \
[Destination] |-{ [Tunnel 5]====[Router 2]---\-----[Frontend 2] \
\ |-{ [Tunnel 6]===/ \ \ \ \
[LeaseSet]--| [Balancer] [Backend]
|-{ [Tunnel 7]===\ / / / /
|-{ [Tunnel 8]====[Router 3]---/-----[Frontend 3] /
|-{ [Tunnel 9]===/ / /
| / /
|-{ [Tunnel 10]==\ / /
|-{ [Tunnel 11]===[Router 4]---------[Frontend 4]
-{ [Tunnel 12]==/
General client process
``````````````````````
- Load or generate a Destination.
- Open up a session with each router, tied to the Destination.
- Periodically (around every ten minutes, but more or less based on tunnel
liveness):
- Obtain the fast tier from each router.
- Use the superset of peers to build tunnels to/from each router.
- By default, tunnels to/from a particular router will use peers from
that router's fast tier, but this is not enforced by the protocol.
- Collect the set of active inbound tunnels from all active routers, and create a
LeaseSet.
- Publish the LeaseSet through one or more of the routers.
Differences to I2CP
```````````````````
To create and manage this configuration, the client needs the following new
functionality beyond what is currently provided by [I2CP] :
- Tell a router to build tunnels, without creating a LeaseSet for them.
- Get a list of the current tunnels in the inbound pool.
Additionally, the following functionality would enable significant flexibility
in how the client manages its tunnels:
- Get the contents of a router's fast tier.
- Tell a router to build an inbound or outbound tunnel using a given list of
peers.
Protocol outline
----------------
Client Router
---------------------> Create Session
Session Status Get Fast Tier
Peer List Create Tunnel
Tunnel Status Get Tunnel Pool
Tunnel List Publish LeaseSet
---------------------> Send Packet
Send Status