Descargando en P2P

Hace tiempo un amigo me comentó que limitaba la velocidad de subida de su eMule porque así bajaba las cosas más rápido.

Esto me pareció una gran tontería porque los canales de subida y de bajada son totalmente independientes (eso creía yo en aquel momento, la buena vieja teoría aprendida en clase). Tras discutir con él un rato me mandó una captura similar a esta (la que os enseño es de Azureus, un cliente de BitTorrent).

En la captura la gráfica inferior representa las velocidades de subida y en la superior las de bajada. Hacia la mitad de la gráfica inferior se aprecia el momento en que limité la velocidad de subida a 11kB/s y se constata en la gráfica superior que la velocidad de descarga aumenta en un factor dos (el doble, para entendernos).

Como antes decía, los canales de subida y de bajada de la línea de conexión a internet son totalmente independientes. ¿Cómo es posible entonces esta aparente paradoja?

La respuesta está en el modelo OSI de 7 capas y el protocolo TCP/IP (que ocupa dos de las 7 capas). Sin meterme en mucho jaleo, este modelo establece una separación de los diversos aspectos que intervienen en una comunicación entre distintas máquinas. Así tenemos la capa del nivel físico, la del nivel de enlace de datos, la del nivel de red, etc, etc.

La paradoja anterior se desvanece al tener esto en cuenta. En el nivel físico los canales son independientes (las descargas usan unas frecuencias distintas a las subidas de modo que pueden viajar por el cable sin interferirse mutuamente) pero a otros niveles no lo son. Intentaré explicarlo:

Cuando me estoy bajando el último capítulo de Naruto mi programa P2P hace una petición al servidor, algo como "mándame el último capítulo de Naruto". Esta petición es un paquete de datos que va en el sentido "mi máquina -> otra máquina" y que por tanto es una subida y que por tanto ocupa un trozo del canal físico de subida. Si este canal está saturado porque estoy subiendo los cinco capítulos anteriores sin imponerle ningún límite, mi petición tardará un tiempo en poder ser enviada al servidor y por tanto tardará un tiempo en ser atendida. Resultado: voy a tardar más en recibir el capítulo que tantas ganas tengo de ver. (Si no se entiende os pongo una metáfora con un túnel en hora punta y unos repartidores de pizzas :D ).

La paradoja está resuelta: la subida y bajada son independientes en la capa física pero no en algunas de las capas lógicas de la comunicación.

Por cierto, os recuerdo que la capa física del modelo OSI es la que está debajo del todo. ¿Por qué os recuerdo esto? Pues porque algún listillo ya estará pensando que si limita el ancho de banda al mínimo su ancho de banda de descarga subirá consecuentemente. Esto indicaría que no se ha entendido muy bien mi explicación. El problema con el que tratamos es de saturación, por lo tanto el límite que tenemos que poner es el mínimo necesario para eliminarla. Es decir, hay un umbral para el que el ancho de subida deja de estar saturado (en mi caso tengo 12 kBps de subida y lo limito a 11kBps de modo que queda como mínimo 1kBps libre) y reducir más el ancho de banda de subida no tiene ningún efecto sobre la velocidad de descarga.

De hecho, normalmente los programas P2P suelen limitar automáticamente la velocidad de descarga proporcionalmente a la velocidad que el usuario establezca como límite de subida.