Há algumas técnicas que pode ser feitas para melhorar o desempenho percebido do I2P - algumas são relacionadas à CPU, outras à banda; banda-larga; largura de banda e outras ao protocolo. Entretanto, todas essas melhorias afetam a latência, tráfego, e o desempenho da rede, ao mesmo tempo em que reduzem a concorrência por recursos escassos. Esta lista não é completa, mas cobre as mais importantes conhecidas.

Para os ganhos de desempenho conquistados, ver o Histórico de Desempenho.

Melhor determinação de perfis e seleção de pares

Provavelmente uma das partes mais importantes para alcançar a melhoria do desempenho será melhorar a forma como os roteadores escolhem os pares pelos quais constroem túneis - certificando-se de não usar pares com links lentos ou com links rápidos mas sobrecarregados, etc. Além disso, precisamos ter certeza de não nos expormos a um ataque Sybil por um adversário poderoso com máquinas muito rápidas.

Refinamento do banco de dados de rede

Queremos ser mais eficientes no reparo do banco de dados da rede e dos algoritmos de manutenção - em vez de constantemente varrer a rede em busca de novos pares - causando um grande número de mensagens e carga no roteador - podemos retardar ou até mesmo parar a busca desde que ela não detecte que há algo novo para varrer (por exemplo, retardar a taxa de varredura dependendo da última vez que algum par nos deu uma referência a algum outro par desconhecido). Também podemos melhorar o que realmente enviamos - quantos pares nós saltamos de volta (ou até mesmo se nós saltamos de volta uma resposta), também podemos melhorar quantas buscas simultâneas fazemos.

Sintonia da Etiqueta Da Sessão e Melhorias

A forma como o algoritmo ElGamal/AES+EtiquetaDaSessão funciona é gerenciando um conjunto de 32 bytes aleatórios-de-uso-único, e expirando-os quando não são usados com rapidez suficiente. Se as expirarmos muito cedo, nós somos forçados a recorrer a uma criptografia ElGamal completa (muito cara), mas se não os expiramos a tempo, temos que reduzir seu número para que não fiquemos sem memória (e se o destinatário de alguma forma for corrompido e perder algumas etiquetas, ainda mais falhas de criptografia podem ocorrer antes da detecção). Com alguns algoritmos ativos de detecção e reação, podemos ajustar de forma segura e mais eficiente a vida útil de uma etiqueta, substituindo a criptografia ElGamal por um algoritmo mais trivial como AES.

Algumas idéias adicionais para melhorar o envio da Etiqueta Da Sessão estão descritas na página ElGamal/AES+EtiquetaDaSessão.

Migrar EtiquetaDaSessão para PRNG sincronizado

Neste momento, nosso algoritmo ElGamal/AES+EtiquetaDaSessão funciona etiquetando cada mensagem criptografada com um aleatório único "32 byte nonce" (uma "Etiqueta Da Sessão"), identificando a mensagem como sendo criptografada com a chave de sessão AES associada. Isto evita que os pares distingam mensagens que fazem parte da mesma sessão, já que cada mensagem tem uma nova etiqueta completamente aleatória. Para conseguir isso, a cada poucas mensagens agrupam todo um novo conjunto de etiquetas da sessão dentro da própria mensagem criptografada, criando uma forma transparente de identificar mensagens futuras. Portanto, precisamos acompanhar quais mensagens são entregues com sucesso para sabermos quais etiquetas podemos usar.

This works fine and is fairly robust, however it is inefficient in terms of bandwidth usage, as it requires the delivery of these tags ahead of time (and not all tags may be necessary, or some may be wasted, due to their expiration). On average though, predelivering the session tag costs 32 bytes per message (the size of a tag). As Taral suggested though, that size can be avoided by replacing the delivery of the tags with a synchronized PRNG - when a new session is established (through an ElGamal encrypted block), both sides seed a PRNG for use and generate the session tags on demand (with the recipient precalculating the next few possible values to handle out of order delivery).

Longer lasting tunnels

The current default tunnel duration of 10 minutes is fairly arbitrary, though it "feels okay". Once we've got tunnel healing code and more effective failure detection, we'll be able to more safely vary those durations, reducing the network and CPU load (due to expensive tunnel creation messages).

This appears to be an easy fix for high load on the big-bandwidth routers, but we should not resort to it until we've tuned the tunnel building algorithms further. However, the 10 minute tunnel lifetime is hardcoded in quite a few places, so substantial effort would be required to change the duration. Also, it would be difficult to maintain backward compatibility with such a change.

Currently, since the network average tunnel build success rate is fairly high, there are no current plans to extend tunnel lifetime.

Acertar os tempos-de-vida

Yet another of the fairly arbitrary but "okay feeling" things we've got are the current timeouts for various activities. Why do we have a 60 second "peer unreachable" timeout? Why do we try sending through a different tunnel that a LeaseSet advertises after 10 seconds? Why are the network database queries bounded by 60 or 20 second limits? Why are destinations configured to ask for a new set of tunnels every 10 minutes? Why do we allow 60 seconds for a peer to reply to our request that they join a tunnel? Why do we consider a tunnel that doesn't pass our test within 60 seconds "dead"?

Each of those imponderables can be addressed with more adaptive code, as well as tunable parameters to allow for more appropriate tradeoffs between bandwidth, latency, and CPU usage.

Aperfeiçoamentos no protocolo de streaming completo

• Perhaps re-enable the interactive stream profile (the current implementation only uses the bulk stream profile).
• Client level bandwidth limiting (in either or both directions on a stream, or possibly shared across multiple streams). This would be in addition to the router's overall bandwidth limiting, of course.
• Listas de controle de acesso (permitindo apenas streams para ou a partir de certos destinos conhecidos).
• Web controls and monitoring the health of the various streams, as well as the ability to explicitly close or throttle them.

Ideias adicionais para melhorias na biblioteca de streamings estão descritas na página da biblioteca de streamings.