What makes I2Speed WiFi-friendly?


As you may already know, I2P uses two transports, NTCP and SSU, that rely on the internet protocols TCP and UDP respectively. TCP is designed to handle packet loss transparently to the application developer, for UDP this is left to the application itself. I2P models UDP data transmission after TCP since the beginning.

Here we get into trouble when we or someone else routing our tunnels runs on a WiFi network. In WiFi networks packet loss is a frequent condition, ranging from 2% upward to really high numbers on crowded networks. However TCP was designed for fixed networks and takes packet loss as a sign of "network congestion", reducing transfer speeds and retransmitting data. Decades of work have gone into "TCP congestion control", but the underlying assumption of a fixed network now turned partially false.

Lots of academic research have gone into make TCP more compatible with WiFi, but a switch to a new TCP will be more painful than introducing IPv6, if it ever will happen. Protocols like HTSP today drop less important data when their TCP connection is getting slower, which is no option for I2P. I2Speed uses a non-aggressive approach to transmit UDP data in parallel even if there is some packet loss, drastically increasing transfer speed. It is even possible to run a router with TCP completely disabled without noticing any difference.

You as a user benefit even when connected to a fixed network because your I2P peers may sit on WiFi. Since I2P uses "introducers" over UDP in firewalled scenarios and handles most traffic over UDP during the first hours after startup, roaming users on WiFi-laptops will see the highest benefit. Of course I2Speed is 100% compatible with the existing I2P installations and I2P peers.

Also I2Speed will do a good job pumping UDP data through overloaded network equipment, which you should notice as an improvement. However do not overload your own internet gateway! Things will go worse otherwise.

So give us a try: http://i2speed.i2p/i2pupdate.zip

Something to watch out for: we used a quick hack to the CWND column on /peers. First item is current send window normalized to 1,000 ms, second item current messages in transit (unchanged), third item messages waiting on the outbound queue, fourth column messages currently being retransmitted.

<-- Back