5. DISCRIMINACION, CONGESTION Y COOPERACION
Volvamos a cómo Internet responde a la congestión, y a cómo la discriminación en la red podría afectar a aquella respuesta. He mencionado cómo la congestión en la red ocasiona que los “routers” rechacen algunos paquetes de datos. Cada paquete rechazado tiene algún computador en el extremo de la red que lo está esperando. En algún momento el computador en espera y su contraparte en la comunicación se darán cuenta de que el paquete ha sido rechazado, y llegarán a la conclusión de que la red está congestionada. Por ello, volverán a enviarse el paquete rechazado, pero en respuesta a la congestión en la red ralentizarán la velocidad de transmisión. Una vez que suficientes paquetes han sido rechazados, y suficientes ordenadores han ralentizado la velocidad de transmisión, la congestión finalizará.
Este es un mecanismo muy indirecto de enfrentarse a la congestión –rechazar paquetes, esperar a que los computadores en el extremo detecten la pérdida de paquetes y responden con la reducción de velocidad- pero funciona perfectamente. Un aspecto interesante de este sistema es que es voluntario. El sistema utiliza a los ordenadores terminales para reducir la velocidad cuando la congestión es detectada, pero nada obliga a los ordenadores terminales a actuar de esta manera. Podemos imaginarlo como un acuerdo amable entre computadores terminales, en el cual cada uno de ellos se compromete a reducir la velocidad de transmisión si sus paquetes son rechazados (recordemos que ésta es otra aplicación del “principio extremo-a-extremo” que mencionamos antes).
Pero hay un incentivo a incumplir este acuerdo. Supongamos que tú incumples -cuando tus paquetes son rechazados continuas enviándolos con tanta velocidad de transmisión como puedes-, y que todos los demás cumplen el acuerdo. Cuando tus paquetes son rechazados, la congestión continúa. Por ello los paquetes de otros son rechazados, hasta que suficientes usuarios ralentizan su velocidad de transmisión y la congestión se alivia. Al ignorar las señales de congestión, tú estarías consiguiendo utilizar una parte de los recursos de la red superior a la que proporcionalmente te correspondería.
A pesar del incentivo a incumplir, la mayoría de los usuarios cumplen el acuerdo usando software que reduce la velocidad de transmisión en respuesta a la congestión detectada. ¿Por qué es así?. Una forma de enfocarlo es considerar que hay algún tipo de contrato social por el que los usuarios cooperan con sus iguales, y que los fabricantes de software cooperan programando el software que permite cumplir el acuerdo.
Pienso que una de las razones por las que los usuarios cumplen es por un sentido de equidad. Si creo que la carga de controlar la congestión debe repartirse igualiatariamente entre todos, al menos a largo plazo, entonces me parece equitativo reducir mi velocidad de transmisión cuando me toca hacerlo a mí. En algún momento podría ser uno de aquéllos cuyos paquetes son rechazados, y por ello reduzco mi velocidad de transmisión.
En otra ocasión, por azar, algún otro verá sus paquetes rechazados, y le tocará reducir su velocidad de transmisión. Cada uno logra su parte equitativa.
Pero ahora, supongamos que la red comienza a singularizar a algunos usuarios y a rechazar sus paquetes primero. Ahora, la carga del control de la congestión cae pesadamente sobre ellos y tienen que reducir su velocidad de transmisión mientras otros la mantienen. Repentinamente el acuerdo “yo reduzco mi velocidad si tú reduces la tuya” deja de parecer equitativo, y las víctimas elegidas son más propensas a incumplir el acuerdo y a mantener su velocidad de transmisión incluso cuando la red les exige reducir su velocidad.
Las implicaciones para la discriminación en la red son evidentes. Si la red discrimina enviando señales falsas sobre la existencia de congestión, y las envía preferentemente a determinados ordenadores o aplicaciones, el incentivo de estas máquinas y aplicaciones de cumplir el acuerdo y asumir su carga en el control de la congestión se debilitará. ¿Conducirá ello a una oleada de desafecciones que destruirá la red?. Probablemente no, pero no puedo estar seguro. Pienso que es algo acerca de lo que deberíamos meditar.
También deberíamos escuchar la lección más amplia de este análisis. Si la red discrimina, los usuarios y sus aplicaciones reaccionarán cambiando su conducta.
Corolario:
LA DISCRIMINACIÓN EN LA RED TENDRÁ EFECTOS IMPREDECIBLES.
6. LA ENCRIPTACION COMO CONTRAMEDIDA
Los escenarios de discriminación en la red incluyen, típicamente, a un ISP que aborda el tráfico de los usuarios e impone retrasos u otras penalizaciones en la calidad de la prestación en relación con determinados tipos de tráfico.
Para hacerlo, el ISP debe ser capaz de discriminar entre los paquetes que quiera retrasar y los restantes.Por ejemplo, para penalizar el tráfico VOIP, el ISP querrá distinguir los paquetes VOIP de los restantes.Normalmente, el ISP puede distinguir los paquetes VOIP observando valores característicos en determinados lugares del paquete. Una forma de retorsión de los usuarios es encriptar sus paquetes, suponiendo que los paquetes encriptados no se diferenciarán del resto y que el ISP no podrá distinguirlos del resto.
Pero al hacerlo, el usuario utilizará probablemente una red privada virtual (VPN). Siempre que el ordenador del usuario quiera enviar un paquete, lo encriptará y enviará a un ordenador “punto de salida” fuera de la red del ISP. Este ordenador del punto de salida lo desencriptará y enviará a su destino. Los paquetes entrantes seguirán la ruta inversa, serán enviados al punto de salida donde serán encriptados y enviados al ordenador del usuario. El ISP no verá nada distinto de un flujo bidireccional de paquetes, todos encriptados fluyendo entre el ordenador del usuario y el del punto de salida.
Lo más que el usuario puede esperar de la VPN es forzar el ISP a tratar todos los paquetes del usuario de la misma manera. El ISP puede todavía, sin embargo, penalizar todos los paquetes del usuario o singularizar aleatoriamente determinados paquetes para darles un tratamiento especial, pero estas serían las únicas formas de discriminación que estarían al alcance del ISP. La VPN tiene costes. Los paquetes deben ser encriptados, desencriptados, y reenviados, pero el usuario podría considerar el coste rentable si impide la discriminación del ISP.
(En la práctica, las cosas son algo más complicadas. El ISP podría singularizar los paquetes observando su tamaño y periodicidad. Por ejemplo, una secuencia de paquetes, todos de un cierto tamaño y que fluyen con regularidad de metrónomo, en ambas direcciones, es probablemente una conversación de voz. El usuario podría usar contramedidas como alterar el tamaño y la periodicidad, pero ello puede ser también costoso. Para simplificar, permítasenos asumir que la VPN coloca al ISP en una posición que no le permite singularizar paquetes).
El usuario con su VPN y el ISP están jugando una versión del juego del “gallina” (en el que “pierde” el que antes lo abandona). El ISP quiere discriminar determinados paquetes, pero no en una forma tan radical que el usuario cambie de proveedor o exija un precio mucho menor. El usuario responde haciendo sus paquetes indistinguibles y obligando al ISP a discriminar contra todos sus paquetes.
El ISP puede también usar una estrategia diferente y más efectiva. Si el ISP quiere perjudicar una determinada aplicación y no hay forma de manipular el tráfico del usuario para que afecte a esa aplicación más que a otras, el ISP tiene una vía de sancionar la aplicación objetivo. Recordemos que la VOIP es especialmente sensible a la “oscilación” (cambios impredecibles en el retraso), pero que muchas otras aplicaciones pueden soportar la “oscilación” sin grandes problemas. Si el ISP impone la “oscilación” a todos los paquetes del usuario, el resultado será un gran problema para los servicios VOIP, pero no tendrá mucho impacto en las restantes aplicaciones.
Los intentos de discriminar y de evitar la discriminación conducen a una guerra técnica de medidas y contramedidas con efectos perjudiciales. Muchos recursos se gastan por ambas partes y el daño colateral es posible. Consideremos el ejemplo anterior, donde un ISP bloquea o degrada el tráfico encriptado para evitar que los usuarios utilicen la encriptación para evadir la actividad de clasificación de paquetes del ISP.
Al actuar así, el ISP está estableciendo un “impuesto” sobre el uso de la encriptación. Ello determinará que los usuarios usen menos encriptación con riesgo de su seguridad y privacidad. Después de todo cualquier paquete que pueda ser “inspeccionado” por un ISP también puede ser inspeccionado por un intruso.
Corolario:
LAS CONTRAMEDIDAS TÉCNICAS, COMO LA ENCRIPTACIÓN, NO PUEDEN PROGEGER PLENAMENTE A LOS USUARIOS DE LA DISCRIMINACIÓN.
7. CALIDAD DE SERVICIO
Uno de los argumentos típicos contra la regla sobre neutralidad en Internet es que los proveedores de acceso necesitan ofrecer garantías de calidad de servicio (QoS) para ciertos tipos de tráfico, como el vídeo. Si la calidad de servicio es necesaria, argumentan, y si las reglas imponiendo la neutralidad dañarían la QoS al exigir el mismo trato para todo el tráfico, entonces las reglas sobre neutralidad son perjudiciales. Aquí quiero diseccionar el razonamiento y ver cómo se fundamenta éste, teniendo en cuenta la investigación en computación y la experiencia de ingeniería.
En primer lugar, hay que dejar claro que garantizar QoS para una aplicación significa más que asignarle mucha banda ancha o priorizar su tráfico frente a otras aplicaciones. Estas pueden ayudar, pero no son QoS (o al menos la clase de QoS de la que yo estoy hablando). Lo que los mecanismos de la QoS tratan de hacer es ofrecer garantías específicas de prestación en relación con una aplicación y durante un corto período de tiempo –en otras palabras, no buscan buenas prestaciones en promedio, sino una prestación que es uniforme y predecible-.
Un ejemplo lo aclarará. Como se ha indicado, algunas aplicaciones son más sensibles a la “oscilación” que otras. Si estás descargando una página, y tu conexión se va y no consigues tráfico durante medio segundo, notarás una breve pausa, pero ello no será un gran problema.
Pero si estás teniendo una conversación con alguien, una interrupción de medio segundo puede ser muy molesta. La navegación por la web necesita una banda ancha suficiente en promedio, pero las conversaciones de voz necesitan mejor protección contra retrasos breves. Esta protección es la QoS.
La razón por la que no necesitamos mecanismos especiales de QoS para la navegación es que la banda ancha proporciona prestaciones que casi siempre son suficientemente veloces durante los intervalos de tiempo que son relevantes para la navegación.
Algunas veces, también, hay trucos sencillos que pueden convertir una aplicación sensible a los retrasos en intervalos muy cortos en una que se ve afectada sólo por los retrasos en intervalos más largos. Por ejemplo, el visionado de audio o vídeo pregrabado no necesita QoS, porque es posible utilizar la memoria de almacenamiento, Si estás viendo un video, puedes descargar cada imagen diez segundos antes de verla; un corte de unos pocos segundos no será, por ello, un problema. Esta es la razón por la que la descarga de vídeo y audio funciona perfectamente cuando hay en promedio suficiente ancho de banda.
Hay otros dos usos importantes donde la QoS no se necesita. Primero, si una aplicación necesita una velocidad promedio más alta que la que Internet puede proporcionar la QoS no le ayudará –la QoS hace la velocidad de Internet más uniforme pero no más rápida-. Segundo y menos obvio, si una aplicación necesita mucha menos velocidad promedio que la que Internet proporciona, la QoS también resultará innecesaria. Si la velocidad no cae hasta cero, sino que fluctúa con picos y valles, entonces incluso los valles pueden ser suficientes para proporcionar a la aplicación lo que necesita. Esto es lo que está empezando a pasar con las conversaciones de voz –muchos sistemas VOIP parece que trabajan muy bien sin ningún soporte especial de QoS en la red-.
No podemos decir que la QoS no sea nunca necesaria, pero la experiencia nos dice que es fácil, especialmente para los no expertos, sobrestimar la importancia de la QoS. Es por ello que no estoy convencido, aunque podría estarlo con más pruebas, que la QoS sea un argumento poderoso contra las reglas sobre neutralidad en Internet.
Colorario:
LAS GARANTIAS DE SERVICIO (QoS) SON MENOS IMPORTANTES DE LO QUE SE PIENSA.
8. ¿DEBERIAMOS ADOPTAR UNA POLITICA LEGISLATIVA DE NEUTRALIDAD EN INTERNET?
Los que busquen aquí una medida legislativa concreta se sentirán decepcionados. La cuestión de la neutralidad es más compleja y sutil de lo que creen la mayoría de los partidarios y opositores. Los partidarios de la neutralidad tienen razón al temer que los ISPs, que tienen razones y medios para ello, pueden discriminar en formas difíciles de reparar. Los opositores tienen razón al decir que la aplicación de las reglas de la neutralidad es difícil y propensa al error. Ambas partes tienen razón cuando afirman que una decisión errónea en este ámbito puede tener efectos colaterales indeseados y dañar el desarrollo de Internet.
Hay un buen argumento técnico a favor de no hacer nada de momento y permitir que la situación se desarrolle. La situación actual, con la cuestión de la neutralidad en el orden del día de Washington pero sin reglas todavía adoptadas, es en muchos sentidos la ideal. Los ISPs, sabiendo que su discriminación contribuiría a hacer que la regulación parezca más necesaria, se comportan de la mejor manera. Y, sin reglas sobre discriminación, no tenemos que hacer frente a las difíciles cuestiones de su delimitación legal y aplicación. La protección de una regulación severa tendría el riesgo de efectos colaterales y la protección de una regulación cosmética removería la amenaza de la regulación futura. Es posible mantener la amenaza de la regulación y dejar la cuestión sin solución concreta por el momento. El tiempo nos enseñará más acerca del tipo de regulación necesaria, si es que alguna finalmente lo es.
Edward W. Felten
(Traducción de Guillermo Ruiz Zapatero)
These materials were based on other materials that are copyright (c) EDWARD W.FELTEN, 2006 .The original materials on which this translation work was based were downloaded from [http://itpolicy.princeton.edu/pub/neutrality.pdf]. The nature of the changes made to the work are as follows [translation from English to Spanish].
Esta obra de traducción de Guillermo Ruiz Zapatero está bajo una licencia Reconocimiento-No comercial-Sin obras derivadas 2.5 España de Creative Commons. Para ver una copia de esta licencia, visite http://creativecommons.org/licenses/by-nc-nd/2.5/es/ o envíe una carta a Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.
No comments:
Post a Comment