Il existe quelques techniques principales qui peuvent être appliquées pour améliorer les performances perçues d’I2P. Certaines des suivantes sont liées à l’UCT, d’autres à la bande passante et d’autres encore au protocole. Cependant, toutes ces dimensions affectent la latence, le débit, et les performances perçues du réseau, car elles réduisent les conflits pour des ressources rares. Cette liste n’est bien sûr pas complète, mais elle couvre les techniques principales observées.

Pour les améliorations de performance passées voir l’historique de performance.

Meilleure sélection et profilage du pair

Une des parties probablement les plus importantes pour obtenir la performance plus rapide sera d’améliorer comment les routeurs choisissent les pairs( au travers desquels ils construisent leurs tunnels - en s’assurant qu’ils n’utilisent pas de pairs avec des liens lents ou avec des liens rapides qui seraient surchargés, etc. De plus, nous devons nous assurer que nous ne nous exposons pas nous-mêmes à une attaque Sybil lancée depuis un adversaire puissant avec beaucoup de machines rapides.

Mise au point de la base de données de réseau

Nous allons vouloir être plus efficaces en guérissant la base de données de réseau et les algorithmes de maintenance - plutôt que constamment explorer le keyspace pour de nouveaux pairs - cause d’un nombre important de messages de réseau et de charge de routeur - nous pouvons ralentir ou peut même arrêter d’explorer jusqu’à ce que nous détections qu’il y a quelque chose de nouveau méritant d’être trouvé (ex: dégrader le taux d’exploration en se basant sur la dernière fois que quelqu’un nous a donné une référence de quelqu’un dont nous n’avions jamais entendu parler). Nous pouvons aussi faire certains réglages sur ce que nous envoyons actuellement - sur combien de pairs nous rebondissons (ou même si nous rebondissons en retour une réponse), aussi bien que combien de recherches simultanées nous accomplissons.

Mise au point et améliorations des étiquettes de session

La façon dont l’algorithme ElGamal/AES+SessionTag fonctione est en gérant un ensemble de tableaux de 32 octets à usage unique, et en les faisant expirer s’ils ne sont pas utilisés assez rapidement. Si nous les faisons expirer trop tôt, nous sommes obligés de nous replier en ayant recours à un (coûteux) plein chiffrement ElGamal, mais si nous ne les faisons pas expirer assez rapidement, nous devons réduire leur quantité pour que nous ne soyons pas à court de mémoire (et si le destinataire est d’une façon ou d’une autre corrompu et perd certaines étiquettes, encore plus d’échecs de chiffrement peuvent se produire avant la détection). Avec une certaine détection plus active et des algorithmes de retour d’information, nous pouvons sans risque et plus efficacement ajuster la durée de vie des étiquettes, remplaçant le chiffrement ElGamal avec une insignifiante opération AES.

Des idées supplémentaires pour améliorer la livraison d’étiquettes de session sont décrites sur la page ElGamal/AES+SessionTag.

Migrer l’étiquette de session vers un PRNG synchronisé

Dès maintenant, notre algorithme ElGamal/AES+SessionTag fonctionne en étiquetant chaque message chiffré avec un nonce unique aléatoire de 32 octets (une "étiquette de session"), identifiant ce message comme étant chiffré avec la clé de la session AES associée. Ceci empêche des pairs de distinguer les messages faisant partie de la même session, sachant que chaque message a une nouvelle étiquette complètement aléatoire. Pour accomplir ceci, tous les quelques messages empaquette un tout nouvel ensemble d’étiquettes de session dans le message chiffré lui-même, livrant d’une manière transparente une façon d’identifier des messages futurs. Nous devons alors garder la trace de quels messages sont livrés avec succès afin que nous sachions quelles étiquettes nous pouvons utiliser.

Ceci marche bien et c’est assez robuste, cependant c’est inefficace en termes d’utilisation de bande passante, comme cela exige la livraison de ces étiquettes en avance de temps (et toutes les étiquettes peuvent ne pas être nécessaires, ou certaines peuvent être gaspillés, en raison de leur expiration). En moyenne cependant, pré délivrer l’étiquette de session coûte 32 octets par message (la taille d’une étiquette). Comme Taral l’a suggéré, cette taille peut être évitée en remplaçant la livraison des étiquettes par un PRNG synchronisé - quand une nouvelle session est établie (via un block ElGamal chiffré), les deux côtés essaiment un PRNG pour utilisation et produisent les étiquettes de session sur demande (avec le destinataire pré calculant à l’avance les quelques peu de valeurs suivantes possibles afin de traiter la panne de livraison).

Tunnels de longue durée

La durée actuelle de tunnel est par défaut de 10 minutes, c’est assez arbitraire, quoique cela "va bien". Une fois que nous aurons le code de guérison de tunnel et un code de détection d’échec plus efficace, nous pourrons sans risque varier ces durées, réduisant les charges réseau et UC (dues aux coûteux messages de création de tunnel).

Ceci semble être une réparation facile pour une haute charge sur des routeurs à grande bande passante, mais nous ne devrions pas y recourir jusqu’à ce que nous ayons ajusté le tunnel construisant des algorithmes plus loin. Cependant, la durée de vie de tunnel de 10 minutes est codée en dur dans un bon nombre d’endroits, donc un effort substantiel serait exigé pour changer la durée. Aussi, il serait difficile de maintenir la compatibilité descendante avec un tel changement.

Actuellement, puisque dans le réseau le taux de réussite de construction de tunnel est en moyenne assez élevé, il n’y a actuellement aucun plan visant à étendre la durée de vie de tunnel.

Ajuster les temps d’échéance

Les temporisations actuelles pour diverses activités sont une autre des choses assez arbitraires, mais qui « semblent correcte » que nous avons. Pourquoi avons-nous une temporisation « pair inaccessible » de 60 secondes ? Pourquoi essayons-nous après 10 secondes d’envoyer au travers d’un tunnel différent que celui annoncé par le jeu de baux ? Pourquoi les requêtes à la base de données de réseau sont-elles restreintes par des limites de 60 ou 20 secondes ? Pourquoi les destinations sont-elles configurées pour demander un nouveau jeu de tunnels toutes les 10 minutes ? Pourquoi permettons-nous 60 secondes à un pair pour répondre à notre demande de se joindre à un tunnel ? Pourquoi considérons-nous comme « mort » un tunnel qui ne réussi pas notre test dans les 60 secondes ?

Chacun de ces impondérables peut être abordé avec du code plus adaptatif, et aussi avec des paramètres ajustables pour tenir compte de différences plus appropriées entre bande passante, latence et utilisation de CPU.

Améliorations du protocole full streaming

• Peut-être re-permettre le profil stream interactif (la mise en œuvre actuelle utilise seulement le profil stream en vrac (bulk).
• Limitation de bande passante au niveau du client (ou dans les deux directions sur un flux stream, ou probablement partagée à travers de multiples flux stream). Ceci serait bien sûr en supplément à la limitation de bande passante globale du routeur.
• Listes de contrôle d’accès (permettant seulement des flux vers ou depuis certaines autres destinations connues).
• Contrôles Web et suivi de la santé des divers flux, ainsi que la capacité de les fermer ou de les ralentir explicitement.

Des idées supplémentaires pour améliorer la bibliothèque de streaming sont décrites sur la page de bibliothèque streaming.