Hay varias técnicas para mejorar el rendimiento de I2P - algunas tienen que ver con la CPU, otras con el ancho de banda y otras relacionadas con los protocolos. Sin embargo, todas estas mejoras afectan la latencia, la cantidad de datos enviados y el rendimiento de la red, mientras que reducen la competencia por los recursos escasos. Esta lista no está completa, pero abarca las más importantes que se conocen.

Para ver las mejoras de rendimiento pasadas vea historial de rendimiento.

Mejor selección de pares y sus perfiles.

Probablemente, una de las partes más importantes para conseguir una mejora en el rendimiento será mejorar como los ruters elijen los pares a través de los que construyen los túneles - asegurándose que no utiliza pares con enlaces lentos o con enlaces rápidos pero sobrecargados. etc. Además, tenemos que asegurarnos que no nos exponemos a un ataque Sybil de un adversario con muchos recursos y con máquinas muy rápidas.

Base de datos de la Red I2P

Queremos ser más eficientes en la reparación de la base de datos de la red y los algoritmos de mantenimiento - en vez de explorar la red constantemente buscando nuevos pares - causando un gran número de mensajes y carga en el ruter - podemos frenar o incluso parar la búsqueda mientras no se detecte que hay algo nuevo por explorar (por ejemplo, ralentizar la tasa de exploración dependiendo de la última vez que algún par nos dio una referencia de algún otro par desconocido). También podemos mejorar lo que enviamos - cuantos pares recuperamos (o incluso si recuperamos una respuesta), también podemos mejorar cuantas búsquedas concurrentes hacemos.

Mejoras en las Etiquetas de Sesión

La forma en que funciona el algoritmo ElGamal/AES+SessionTag es administrando un conjunto de arrays de 32 bytes aleatorios de un solo uso, y desechándolos cuando no se usan los suficientemente rápido. Si los desechamos demasiado pronto, tenemos que crear otra vez un cifrado (muy caro) ElGamal, pero si no los desechamos a tiempo, tenemos que reducir su número o nos quedaremos sin memoria RAM (y si al destinatario de alguna forma se le corrompen y pierde algunas etiquetas, pueden ocurrir incluso más fallos en los cifrados). Con algoritmos con detección activa y de control, podemos ajustar de una forma más segura y eficientemente el tiempo de vida de una etiqueta, reemplazando el cifrado ElGamal con un algoritmo más trivial como AES.

Algunas ideas adicionales para mejorar el envío de las Etiquetas de Sesión se describen en la página de ElGamal/AES+SessionTag.

Migrar las Etiquetas de sesión a PRNG sincronizado.

Ahora mismo, nuestro algoritmo ElGamal/AES+SessionTag funciona etiquetando cada mensaje cifrado con un 'nonce' único de 32 bytes (una "etiqueta de sesión"), identificando el mensaje como un mensaje cifrado con la clave de sesión AES asociada. Esto previene que los pares distingan los mensajes que son parte de la misma sesión, ya que cada mensaje tiene una etiqueta nueva completamente aleatoria. Para llevar esto acabo, cada unos pocos mensajes se envuelven un nuevo conjunto de etiquetas de sesión dentro del mensaje cifrado, creando una forma transparente de identificar los mensajes futuros. Por lo tanto tenemos que llevar un control de cuales mensajes han llegado con éxito a su destino para saber que etiquetas debemos usar.

Este sistema funciona bien y es muy robusto, aunque no es eficiente en el uso del ancho de banda, y necesita el envío de estas etiquetas antes de tiempo (y no todas las etiquetas serán necesarias, o se desperdician, debido al tiempo de expiración). De media, enviar con antelación las etiquetas de sesión cuesta 32 bytes por mensaje (el tamaño de una etiqueta). aunque como ha sugerido Taral, ese tamaño puede evitarse reemplazando el envío de etiquetas con un PRNG sincronizado - cuando una nueva sesión se establece (a través de un bloque cifrado ElGamal), ambos lados siembran un PRNG para generar las etiquetas de sesión cuando se necesite (con el destinatarios pre calculando los siguientes valores para poder manejar los envíos)

Tiempo de duración máximo de los túneles.

El tiempo de duración actual de 10 minutes es bastante arbitrario, aunque parece que funciona bien. Una vez que tengamos el código de reparación de túnel y un sistema de detección de fallos más eficiente, podremos cambiar estas duraciones de forma más segura, reduciendo la carga en la CPU y en la red (debido al excesivo costo al crear los mensajes de los túneles).

Esto parece un fácil arreglo para la carga de la CPU y el gasto de ancho de banda en los ruters, pero no podemos usarlos hasta que hayamos afinado mucho mejor los algoritmos de creación de túneles. Aún así, el tiempo de vida de 10 minutos está incluido en varios sitios, con lo que hará falta bastante esfuerzo para cambiar esta duración. Además, será dificil mantener la compatibilidad con versiones anteriores tras este cambio.

Actualmente, ya que el éxito en la creación de túneles de la red es bastante alto, no existen planes para aumentar el tiempo de vida de los túneles.

Ajustar tiempo máximo de espera

Otros truquitos arbitrarios que parece que "funcionan bien" usados son los tiempos de vida actuales de varias actividades. ¿Por qué tenemos 60 segundos para el tiempo de vida de "par inaccesible"?¿Por qué intentamos usar un diferente túnel que el LeaseSet nos avisa después de 10 segundos?¿Por qué las consultas a la base de datos está limitada por 60 o 20 segundos?¿Por qué están las destinaciones configuradas para preguntar por un nuevo grupo de túneles cada 10 minutos?¿Por qué permitimos a un par tardar 60 segundos en responder a la petición de unirse a un túnel?¿Por qué consideramos un túnel como "muerto" si no pasa nuestras pruebas en 60 segundos?

Todos estos imponderables pueden solucionarse con un código más adaptativo, al igual que con parámetros afinables que compensen el gasto entre el ancho de banda, latencia y el uso de CPU.

Mejoras en el protocolo de transmisión

• Quizás usando de nuevo el perfil de transmisión interactivo (la implementación actual sólo usa el perfil de transmisión normal).
• Limitación del ancho de banda en el cliente (en una o las dos direcciones de una conexión, o posiblemente compartido entre varias conexiones). Esto será además del límite general de ancho de banda, por supuesto.
• Listas de control de acceso (sólo permitiendo conexiones desde o hacia otras destinaciones conocidas).
• Control por web y monitorización del estado de varias conexiones, además de la posibilidad explícita de cerrarlas o regularlas.

Varias ideas para mejorar la librería de straming se describen en la web de la librería de streaming.