No es del todo cierto:
Aparentemente tú tienes un límite de 600/200. Cierto.
Pero te pongo un supuesto (que afecta directamente a la mula) en la que no es así (y poco importa que hablemos de R, de Ono, o de la pilarica).
Supongamos que estás subiendo un documento por un canal y esa subida está ocupando un ancho de 198 kbps. Aparentemente puedes bajar a 600 kbps y subir algo adicional a 2 kbps. Pero sólo aparentemente. Si repasas tus conocimiento del protocolo TCP-IP, que es en el que todos nos movemos, sabrás que la información se trocea en paquetes y que la red no es más que un montón de paquetes que van y vienen. El problema reside que por cada paquete o por cada conjunto de paquetes que mandes o que recibas, se origina automáticamente un tráfico en sentido contrario para advertir a la otra parte que los paquetes enviados o recibidos han llegado correctamente a su destino o no han llegado. Es un flujo residual pero está ahí.
Bien, retornemos a nuestro ejemplo: como estás subiendo mucha cosa, se origina tráfico de retorno de confirmación y ocupa su pequeño ancho. Pero se presenta inmediatamente un problema: Si tú en otro canal quieres bajarte un documento muy ganso, aunque creas que vas a ocupar los 600kbps, no podrá ser así ¿Por qué? porque el tráfico de retorno (subida) que tienes que mandar al sitio de donde estás bajando material tiene su ancho de banda agotado. En consecuencia los paquetes de confirmación de recepción llegan tarde o no llegan y, el servidor reacciona bajando el ancho de banda hasta que las confirmaciones lleguen con fluidez.
Sería este un caso en el que tú tienes acho de banda teórico suficiente pero, por lo colapsado de una de las direcciones (subida), no se puede aprovechar todo el ancho de banda teórico de bajada.
Es un poco lioso... pero piensa que tú eres la estación de trenes de un sitio y que recibes y mandas trenes (paquetes) a distintos sitios... continua la simulación y verás, que además de divertirte, una cosa es la teoría y otra la práctica.
Besitos.
