L'aggiornamento più recente di questa pagina risale a Agosto 2010 e si riferisce alla versione del router 0.8.

Ci sono alcune tecniche principali che si possono usare per aumentare le prestazioni percepite di I2P: alcune delle seguenti sono relative alla CPU, altre alla larghezza di banda, ed altre ancora al protocollo. Comunque, tutte influiscono sulla latenza, sulla velocità di trasmissione, e sulla prestazioni percepite della rete, perché riducono la lotta per le scarse risorse. Questa lista non è ovviamente esaustiva, ma copre le principali tecniche che si possono usare.

Per conoscere i miglioramenti alle prestazioni apportati in passato, consulta lo Storico delle prestazioni.

Miglior profilo e selezione dei peer

Probabilmente una delle strategie più importanti per aumentare le prestazioni è migliorare come i router scelgono i peer tramite cui costruire il percorso dei tunnel: assicurati che i router non usino peer con collegamenti lenti, né quelli che abbiano collegamenti veloci ma sovraccarichi, ecc. In aggiunta, assicurati di non esporti ai tipi di attacco Sybil perpetrati da un avversario potente che ha a disposizione molti elaboratori veloci.

Affinamento del database di rete

Vorremmo rendere più efficienti gli algoritmi di manutenzione e salute del database della rete, invece di esplorare costantemente la keyspace per nuovi peer: ciò infatti causa incrementa significativamente il numero di messaggi di rete e il carico del router. Possiamo rallentare o anche fermare l'esplorazione fino a che ci accorgiamo che c'è qualcosa di nuovo che val la pena di essere trovato (p. es. diminuire il tasso di esplorazione, basato sull'ultima occasione in cui qualcuno ci ha indicato qualcun altro di cui non sappiamo nulla). Possiamo anche affinare quello che inviamo correntemente: quanti peer rimandiamo indietro (o anche se rimandiamo indietro una risposta), così come quante ricerche effettuiamo in contemporanea.

Miglioramenti e affinamento del tag di sessione

L'algoritmo ElGamal/AES+SessionTag funziona gestendo un insieme di array di 32 byte, utilizzabili solo una volta, eliminandoli se non sono rapidamente usati. Se eliminiamo questi array troppo presto, siamo costretti a una nuova ricodifica di tipo ElGamal, che è dispendiosa; d'altra parte, se non li eliminiamo abbastanza velocemente, dobbiamo ridurre la loro quantità, per non occupare troppa memoria (ed evitare che, se il destinatario presenta errori e perde alcune etichette, ulteriori errori di codifica occorrano primo di essere trovati). Possiamo, in sicurezza e con maggiore efficienza, migliorare la durata delle etichette, utilizzando rilevazioni attive e algoritmi di feedback: ciò si ottiene rimpiazzando la codifica ElGamal con una più banale AES.

Altre idee su come migliorare la spedizione di etichette di sessione sono descritte qui: Pagina di ElGamal/AES+SessionTag.

Migrare sessionTag per sincronizzare PRNG

Adesso, il nostro algoritmo ElGamal/AES+SessionTag lavora etichettando ogni messaggio cifrato con un numero casuale unico di 32, di tipo nonce (una "etichetta di sessione"), che identifica quel messaggio come codificato con la chiave di sessione AES associata. Questo impedisce ai peer di distinguere i messaggi che appartengono alla stessa sessione, visto che ogni messaggio possiede una etichetta casuale completamente nuova. Per far questo, l'algoritmo impacchetta pochi messaggi alla volta ed usa un nuovo insieme di etichette di sessione, all'interno dello stesso messaggio codificato, inviando così, in modo trasparente, un metodo per identificare i messaggi futuri. In seguito bisogna tener traccia di quali messaggi sono stati inviati con successo, per sapere quali etichette possiamo usare.

Questo funziona bene ed è abbastanza robusto, però è inefficiente per quanto riguarda l'uso della larghezza di banda, perché richiede la spedizione delle etichette in anticipo (e non tutte le etichette sono sempre necessarie: alcune possono anche essere sprecate, a causa della loro breve durata). Comunque, mediamente, la spedizione anticipata dell'etichetta di sessione costa 32 byte per ogni messaggio (cioè la dimensione di un'etichetta). Tuttavia, Taral ha suggerito che la dimensione può essere evitata rimpiazzando la spedizione delle etichette con un PRNG sincronizzato: quando si stabilisce una nuova sessione (attraverso un blocco codificato con ElGamal), entrambi i lati diffondono un PRNG da usare e generano le etichette di sessione su richiesta (con il ricevente che calcola anticipatamente i possibili valori futuri per gestire un invio non ordinato).

Tunnel di lunga durata

La durata attuale predefinita di un tunnel - 10 minuti - è del tutto arbitraria, anche se "sembra ok". una volta che avremo un codice che risani il tunnel e una rilevazione dei malfunzionamenti più efficace, saremo in grado di variare questa durata con maggior sicurezza, riducendo il carico della rete e della CPU (a causa dei messaggi di creazione tunnel, avidi di risorse).

Questo sembra una facile soluzione per elevati carichi su router con ampia larghezza di banda, ma non possiamo ricorrere a ciò fino a che non avremo affinato maggiormente gli algoritmi di costruzione del tunnel. Comunque, il ciclo di vita di 10 minuti del tunnel è codificato in molti punti, pertanto un notevole impegno sarebbe richiesto per modificare la durata. Inoltre, sarebbe difficile mantenere la retrocompatibilità con una tale modifica.

Attualmente, siccome la media delle percentuali di successo nella creazione di tunnel della rete è piuttosto alta, non abbiamo pianificato di estendere la durata dei tunnel.

Impostare i timeout

I timeout attuali per varie attività sono un altro esempio di impostazioni abbastanza arbitrarie ma che "sembrano ok". Perché abbiamo un timeout di 60 secondi per il "peer irraggiungibile"? Perché cerchiamo di inviare, dopo 10 secondi, attraverso un tunnel diverso che ci mostra un LeaseSet? Perché le richieste al database di rete hanno un limite temporale di 20 o 60 secondi? Perché le destinazioni sono impostate per richiedere un nuovo insieme di tunnel ogni 10 minuti? Perché concediamo 60 secondi ad un peer per rispondere alla nostra richiesta di unirsi al tunnel? Perché consideriamo "morto" un tunnel che non supera i nostri test entro 60 secondi?

Ciascuna di queste evenienze può essere risolta con un codice più adattivo, e anche con parametri di affinamento che permettano un adeguato compromesso tra larghezza di banda, latenza e uso della CPU.

Miglioramenti al protocollo di Full streaming

  • Probabilmente riabilitare il profilo interattivo dello stream (l'implementazione corrente usa solo il profilo di stream puro).
  • Limitare il livello della larghezza di banda di un client (in una o entrambe le direzioni di un flusso, o eventualmente condiviso attraverso flussi paralleli). Questo sarebbe ovviamente in aggiunta al limite medio di larghezza di banda del router.
  • Liste di controllo accesso (permette lo stream solo da o per alcune destinazioni conosciute).
  • Controlli web e salute dei vari flussi, e anche la capacità di chiuderli esplicitamente oppure troncarli.

Altre idee per migliorare la libreria di streaming sono descritte nella pagina della libreria di streaming.