El blog de los empleados
de Telefónica I+D

Siempre que se habla del futuro de internet, una cosa sale a relucir: más velocidad. Aunque con el ADSL ya vemos ofertas de 20 Mbits por segundo, cuando tengamos fibra, todo será más rápido. Pero, ¿qué harías tú con 30 Mbits por segundo de bajada?

Bien, repasemos las “killer app” de internet. Hemos pasado por el correo, la mensajería instantánea, el streaming de vídeo y el P2P, que supone un gran porcentaje de los datos que circulan por la red de redes.

Foto de MaRS, licencia Creative Commons

No cabe duda de que con más ancho de banda podríamos ver vídeos por streaming de mucha más calidad y disponer de vídeo a la carta y contenidos en HD y demás. Evidentemente, si queremos ver contenidos diferentes en habitaciones diferentes de la casa, necesitaremos aún más ancho de banda.

Pero, espera, espera. Eso supondría que un hogar compraría películas o series para verlas por streaming directamente desde el servicio. Pero actualmente, NO hacemos eso. Sí, vemos algún vídeo de Youtube y tal, pero el inmenso porcentaje de contenidos que vemos no es por streaming, sino descargado. Y no tenemos prisa en que se descargue más o menos rápido, que tarde dos horas o una semana: cuando termine, ya lo veremos. Sí, claro, con más velocidad bajaría más rápido, pero, ¿alguien tiene tiempo para ver todo lo que se bajaría con una conexión de 6 Mb/s si estuviera bajando cosas en ciclo 24×7? Es decir, vista la tendencia del consumidor de contenidos español, ¿se prevé un gran negocio en el consumo de contenidos de pago por streaming?

Bien, parece que la visualización de contenidos por streaming de alta calidad sí llenaría ancho de banda pero parece dudoso que el internauta español medio pagase por ello si le están dando X Mbits/s que podría utilizar para bajárselo por P2P. Suena extraño que alguien pagase Y euros/mes por una conexión de alta capacidad y además, Z por cada contenido que quisiera ver. Y ojo, que muy probablemente este internauta medio siga comprando DVDs, vaya a un montón de conciertos y al cine y lea muchos libros y revistas.

Sería interesante ver la opinión de dicho internauta medio repecto a si pusiéramos los contenidos para ver por streaming, en HD (o al menos en calidad DVD), por una tarifa plana. Pagas X euros al mes y ves todo lo que quieras del catálogo de contenidos, sin encontrarte sorpresas como películas porno después de estar una semana bajando el piloto de esa serie tan prometedora o imagen de tan baja calidad que no hay manera de saber si ese que está en pantalla es Brad Pitt o Chiquito de la Calzada. ¿Una locura? Bueno, a Netflix no parece irle mal con este sistema (aunque es complementario al alquiler de DVDs), pero más locura parece lo de Hulu, que es gratis. ¿Puede ser el streaming gratuito y subvencionado por publicidad la solución?

Foto de rq, licencia Creative Commons

Y, sobre todo, no olvidemos el sueño de todo usuario: acceder a su colección de contenidos desde cualquier lugar y plataforma de manera fácil y, además, poder compartirla con sus contactos. ¿No se inclinaría el usuario medio por la fibra si se le diera esa posibilidad?

El pasado dia 23 de Marzo comenzó en San Francisco la edición para el año 2009 del GDC. Si bien no se presentaron muchos conceptos nuevos, al menos si hubo presentaciones interesantes y , en concreto, el lanzamiento de un producto que a la vista de todos los expertos podria revolucionar el mercado de los video juegos, OnLive.

• Productos:
  • Juegos basados en cámaras: Tras la reciente aparición de nuevos interfaces para los videojuegos como pueden ser las pantallas tátiles o los controles de la conocica consola Wii los desarrolladores siguen planteandose nuevos retos en este ámbito y uno de los posibles nuevos productos son los juegos basados en cámaras. Estos juegos serán controlados por el jugador mediante cámaras 3D que capturarán cada movimiento con seis grados de libertad y harán que el personaje actue en consecuencia. Esta tecnología va más allá del control mediante una cámara anteriormente conocido como puede ser el eyeToy ya que las imagenes procesadas serian tridimensionales y no planas.
  • Juegos para terminales móviles: Con la aparición del iPhone no sólo se ha revolucionado el campo de la telefonia movil y los smartphones si no que se ha descubierto todo un nuevo mundo de terminales móviles suficientemente potentes como para ejecutar buenos juegos y no sólo pasatiempos. Debido a esto varios expertos aseguran que parte de los desarrolladores deberian cambiar mover parte de sus esfuerzos para la creación de juegos para este nuevo tipo de terminales.
• OnLive:
  
  Este ha sido sin duda el producto más destacado de toda la conferencia de desarrolladores y no sólo por la posible revolución del mercado de los video juegos que plantea si no por el reto tecnológico que a primera instancia presenta. Onlive propone un cambio de paradigma a la hora de jugar con una consola. Destierran la idea de comprar un soporte físico con el juego e incluso la propia consola. Su idea consiste en que cada jugador simplemente tenga una pantalla con la que jugar y una conexión a internet. Las ordenes generadas por los controles se enviarian a los centros de cálculo de la empresa donde se interpretarian, se ejecutaria el juego, se capturaria la salida de video , se comprimiria y se enviaria hacia el jugador como un streaming de video normal.

Continuamos la serie de entradas dedicada a las tendencias tecnológicas para el año 2009 y más allá.

Siguiendo con los dispositivos, merece la pena recoger lo que los fabricantes de teléfonos móviles han presentado en distintos eventos con su visión del futuro.

Sony Ericsson, en una conferencia de prensa (“Mobile Phones Will Shoot Full HD Video in 2012“), con el horizonte puesto en 2012, habla de dispositivos muy potentes, equivalentes en capacidad de cálculo a los ordenadores convencionales, y alimentados con conexiones a 100Mbps bajo la llamada “HSPA evolution”. Contarán con cámaras en el rango de los 12 a 20 Megapíxeles que permitirían grabar video Full HD. En el otro extremo, contarían con pantallas con resolución XGA (para vídeo HD es preciso llegar a 720 ó 1080 píxeles).

La Agenda 2015 de Nokia se fija en los principales temas hacia los que se va a enfocar su actividad de innovación, lo que hace que sea más una guía de tendencias futuras que de referencias concretas. Las ocho áreas clave definidas por Nokia son:

• Modelado de usuarios y su contexto, lo que no sorprende en absoluto ya que la personalización y adaptación al contexto son temas con una fuerte proyección en todo el mundo de las tecnologías de la información.
• Dispositivos móviles adaptativos, sacando partido del punto anterior.
• Interfaces “humanos”, o más bien interfaces adaptativos que evolucionan con sus usuarios.
• Realidad “mezclada”, o enriquecida, o aumentada, el término más habitual para estas técnicas.
• Creatividad: medios para fomentar y canalizar la creatividad colaborativa de los usuarios.
• Plataformas de servicio escalables. Otra tendencia aceptada generalmente dadas las magnitudes que alcanza rápidamente cualquier servicio con éxito.
• Internet of Things, definida como la capacidad para percibir, interactuar y localizar cualquier cosa en cualquier sitio.
• “Dynamic Wireless”, servicios que permiten usar dinámicamente los recursos en red, sobre todo los liberados. Parece que apuntan a teléfonos móviles que no se ciñan a una única tecnología (GSM, UMTS, …)

Estos y otros nuevos dispositivos ayudarán a ahondar en la fuerte tendencia hacia el acceso ubicuo a servicios y informaciones. Un mundo “todo online” en el que sea muy fácil acceder a los datos y herramientas personales, desde cualquier lugar, y sin tener siquiera que contar con dispositivos propios. Esto supondrá una migración masiva hacia la red, y una mejora en acceso, fiabilidad y precios de las redes. Este movimiento es universal, aunque a distintas velocidades: mientras en algunos países se manifiesta en la adquisición de un teléfono móvil y el uso de SMS, en otros supone el acceso móvil a la banda ancha y el despliegue de fibra. Éste último proceso será uno de los más decisivos en 2009.
Una consecuencia de esta mayor conectividad será que la gestión de la identidad se convertirá –más aún- en un elemento crítico. Las amenazas de todo tipo se volverán más complejas y sofisticadas, en este terreno y en el de la seguridad, que puede alcanzar nuevas cotas en difusión e intensidad de ataques y amenazas.
La multitud de dispositivos disponibles, el hecho de que los usuarios tiendan a contar con varios de ellos, y que esperan recibir una misma la información y servicios en ellos, hace muy necesario el desarrollo de soluciones de sincronización que simplifiquen la gestión y mejoren la experiencia de los usuarios.
Otra dimensión más de la tecnología centrada en el usuario, es la localización. No es una novedad, 2008 ha visto un enorme crecimiento, pero 2009 puede ser el momento de la definitiva popularización y difusión de los servicios basados en el uso del GPS y otras tecnologías similares junto con la banda ancha móvil.
Aunque aún retenga gran parte de su importancia los contenidos locales, y la ejecución de aplicaciones sobre los dispositivos personales, a medio plazo el acceso ubicuo propiciará una migración hacia “The Cloud” la nube de recursos de proceso, almacenamiento y conexión en la que cada vez más empresas confían sus recursos, y que alberga un número creciente de servicios y aplicaciones para los usuarios finales. En 2009 seguiremos viendo nuevas propuestas de nubes desde distintos actores, aún lejos de la etapa de consolidación y clarificación del mercado.
El desarrollo de las soluciones cloud se verá beneficiado por la crisis, ya que una de sus promesas es la de un ahorro de costes derivado de la virtualización de planta, y la flexibilidad de configuración, muy atractivas para muchas empresas.

En cuanto a contenidos, parece que la creciente predilección por los juegos en lugar de otros modos de entretenimiento, como el cine, será más acusada, y eso tiene importantes consecuencias en varios frentes: una mayor predilección por pasar más tiempo en casa (a lo que ayudará la crisis), adquisición de equipos complementarios para consolas (un mercado con un crecimiento enorme y sin la competencia de la piratería), una mayor predilección por los juegos en red, y un relativo declive de soportes y medios para la reproducción de audiovisuales. En los últimos dos años se está detectando un deterioro en la calidad de las producciones cinematográficas convencionales, a favor de las series y los juegos. Nuevos formatos, como el cine 3D, están tratando de sacar a los espectadores de casa y llevarlos a salas cada vez más vacías.
El declive de los medios convencionales, especialmente en los impresos, desde los periódicos a los libros, será más acusado por el efecto de la crisis, aunque tampoco hay que dejar de lado las señales de alarma que se ciernen sobre la televisión, siempre a favor de medios interactivos y basados en la conectividad, esencialmente juegos y servicios de Internet.

La Web 2.0 se ampliará y consolidará llegando por un lado a capas cada vez más amplias de la población, y por otro, el de los usuarios más inquietos, ampliando el efecto de una tendencia que vimos nacer recientemente: el microblogging y el lifestreaming, que será, sobre todo éste último, el que alcance mayor protagonismo en 2009.

La crisis también va a suponer un apoyo decisivo para el freeware y los servicios y contenidos gratuitos, muy baratos o pagados con publicidad. El éxito de la App Store del iPhone con precios muy bajos está marcando el camino.

Hay quien pronostica un futuro prometedor para reconocimiento de voz, sobre todo apoyado en aplicaciones móviles sobre dispositivos personales. Los asistentes personales empezarían así a popularizarse a lo largo de 2009.

La eficiencia y el ahorro energético, la presencia ubicua del prefijo “eco-“, o de un matiz verde a todo lo que rodee la tecnología será tan habitual que no parecerá una tendencia innovadora. La presión hacia el enfoque energético va a depender mucho de la evolución de los precios, impredecibles a causa de la crisis.

Menos evidentes, hay otros movimientos que no hay que dejar de lado, sobre todo por que impacto será manifestará a medio plazo. Por ejemplo, los desarrollos en pantallas, con dispositivos flexibles, tecnologías OLED, y las primeras experiencias masivas en papel electrónico, que en breve será en color.
HTML 5 es la nueva versión de un elemento básico en la Web, y que yace olvidado bajo capas de código y una legión de herramientas. La adopción de esta nueva versión simplificará la implementación de funcionalidades complejas, acelerando el desarrollo de servicios.

Además de las limitaciones asociadas al tamaño máximo que puede alcanzar la ventana, nos encontramos con la problemática adicional de que TCP, prudentemente, no empieza la transferencia con el tamaño definitivo de ventana. Por el contrario, como ya hacía la empresa de paquetería de nuestro ejemplo, TCP comienza con una ventana de un solo paquete y la va aumentando poco a poco hasta detectar el punto “de saturación”.

En consecuencia, la velocidad de transferencia no será la máxima posible desde el primer momento, sino que irá creciendo paulatinamente hasta estabilizarse alrededor del ancho de banda disponible. Por tanto, habrá un tramo al principio de cualquier conexión (al que se denomina, “fase de slow start”) en el que el caudal aún no ha alcanzado la capacidad realmente disponible. Este período será tanto mayor cuanto más alta sea la velocidad final que deba alcanzarse. Así, este comportamiento “prudente”, que es muy adecuado para evitar problemas de congestión en la red, supone una dificultad significativa para estimar la velocidad de un acceso de alta capacidad.

Para entender mejor la importancia del problema, supongamos que un piloto de Fórmula 1 quisiera medir la velocidad que su bólido es capaz de obtener en un determinado circuito y que, para ello, pidiera que le cronometrasen el tiempo que tarda en dar 4 vueltas. Si el piloto comenzara la prueba ya lanzado a su máxima velocidad, podríamos estimar esta velocidad dividiendo la distancia total recorrida (4 vueltas al circuito) por el tiempo total invertido. Sin embargo, si para evitar problemas con los neumáticos, nuestro piloto decidiera hacer la primera vuelta en 1ª, la siguiente en 2ª, y así sucesivamente, está claro que la estimación de velocidad que hemos hecho sería totalmente errónea, pues, a la 4ª vuelta aún no habría llegado, ni mucho menos, a utilizar la marcha más rápida del vehículo.

Llegados a este punto, nuestro piloto tendría dos soluciones posibles:

• Prolongar la prueba lo suficiente para que la inclusión del período de “calentamiento” acabe por suponer un error despreciable en la medida.
• Descartar completamente la fase de “calentamiento” y comenzar a medir cuando estemos seguros de que el coche está corriendo a su máxima velocidad.

De la misma manera, en un test de velocidad deberemos garantizar que el período de slow start no afecta significativamente a la medida, asegurándonos de que la descarga es suficientemente grande para que se llegue a la máxima ventana y que esta primera fase de “aceleración” no sesga significativamente la estimación. Desgraciadamente, en los tests que siguen las metodologías habituales, se descarta directamente la segunda opción (excluir el slow start) y se confía exclusivamente en que la duración de la prueba sea suficiente.

Para hacernos una idea de los órdenes de magnitud, a continuación se muestran los tamaños de descarga de algunos de los tests de velocidad más populares en España:

Como puede apreciarse, los Tests A, B y C tienen el mismo tamaño de descarga, 7,5 Mbytes (el tamaño típico de un test de Ookla), mientras que el Test D emplea una descarga aún más pequeña.

¿Son suficientes estos tamaños de descarga? Para comprobarlo, representaremos la evolución real del caudal de una conexión TCP en un acceso de 30 Mbps y el resultado que se obtiene con un test convencional de velocidad (que sume los bytes totales transferidos y los divida por la duración de la prueba hasta ese momento). Así mismo, se representará en la misma gráfica el resultado que se obtendría con un test “alternativo” en el que modificásemos la metodología que conocemos, para excluir explícitamente la fase de slow start.

Como puede apreciarse, en un test de velocidad convencional se necesitan varias decenas de Mbytes para estimar con cierta precisión el ancho de banda del acceso de 30 Mbps. Así, los tests de velocidad A, B y C (7,5 Mbytes) estimarían, en el mejor de los casos, unos 25 Mbps (83% del valor real), mientras que el Test D, apenas llegaría a los 20 Mbps (menos del 70%). Así mismo, cabe destacar que, empleando una metodología alternativa que excluyera directamente la fase de slow start, sería posible obtener una estimación bastante precisa con descargas de algo menos de 1 MByte.

CONCLUSIONES

Los tests de velocidad están llamados a jugar un importante papel en la evaluación de la calidad del servicio de banda ancha. Al tradicional rol de “auditores de la banda ancha”, cuyo impacto desborda el ámbito del propio sector TIC y comienza a calar en la opinión pública en general, se une el posible papel que puedan desarrollar en un futuro próximo dentro del ámbito regulatorio. Para desempeñar correctamente estos dos cometidos y que su labor finalmente se traduzca en la mejora de los servicios de banda ancha y en el aumento de la transparencia del mercado, es necesario que éstos realicen su cometido con la mayor fiabilidad y precisión.

Sin embargo, después del análisis pormenorizado de estos tests de velocidad y sus metodologías de medida, nos encontramos con que una gran parte de los medidores actualmente disponibles, aunque siguen siendo adecuados para las modalidades tradicionales de acceso, no consiguen hacer estimaciones fiables de velocidad en los nuevos accesos de alta capacidad. Así, factores como la configuración de ventana TCP en el equipo de cliente o en el propio servidor, que conducen a serias limitaciones en la velocidad máxima que puede medirse, siguen sin tenerse en cuenta a la hora de contrastar los resultados de una estimación de velocidad.

De la misma manera, problemas latentes en la propia metodología de medida, que permanecían ocultos a bajas velocidades, parecen tener ahora un efecto más evidente. Tal es el caso de la inclusión sistemática de la fase de slow start de TCP en el cómputo global de la medida, lo que, a altas velocidades, comienza a producir desviaciones más que significativas.

A la mejora continuada de estos sistemas de medición habrán de dedicar una buena dosis de atención todos los agentes implicados, de manera que dispongamos los usuarios de medios adecuados para controlar la calidad del servicio que se nos ofrece, y que esto pueda traducirse finalmente en una mejora continuada en nuestra experiencia con la banda ancha.

ENTRADAS DE ESTA SERIE:

1. La importancia de una estimación precisa.
2. ¿Cómo funciona un test de velocidad?
3. TCP, la empresa de paquetería.
4. Las limitaciones de la ventana (o cómo el sistema operativo sabotea nuestra medida).
5. El crecimiento gradual de la ventana (o cómo el fichero de descarga se nos queda pequeño).

Como vimos en el post anterior, si TCP sólo enviase un paquete cada vez y esperase a la llegada de su ACK para mandar el siguiente, podría llegarse a la paradoja de que el retardo de propagación de ida y vuelta (RTT) se convirtiera artificialmente en el cuello de botella de la transmisión, en lugar de serlo la propia capacidad del enlace (sólo se enviaría un paquete por cada ciclo de RTT). Por ese motivo, TCP mantiene un número determinado de paquetes “en vuelo” sin haber recibido aún su confirmación, de manera que es capaz de aprovechar eficientemente el enlace. A este número de paquetes “en vuelo” es a lo que se denomina ventana.

El tamaño adecuado de esa ventana se calcula dinámicamente a lo largo de la conexión, adaptándose al RTT que haya en cada momento, de manera que en cada ciclo de RTT se manden suficientes paquetes para ocupar el ancho de banda disponible (lo que equivale a “llenar la cinta transportadora” en el ejemplo anterior).

Sin embargo, el margen que tiene el protocolo TCP para adaptar dinámicamente su ventana no es indefinido. Además de las limitaciones que dicte la propia capacidad de la línea, TCP tiene que trabajar de acuerdo a los valores máximos de ventana que estén configurados en los sistemas operativos de cada uno de los extremos, de manera que en ningún caso se le permitirá trabajar con una ventana que supere en tamaño a los valores máximos prefijados en el emisor y el receptor.

De esta forma, una conexión TCP sólo será capaz de aprovechar al máximo el ancho de banda disponible si ambos extremos tienen una configuración de ventana máxima suficientemente holgada para las condiciones de funcionamiento. En particular, los tamaños de ventana TCP tanto del extremo receptor como del emisor deben ser suficientes para trabajar con las condiciones de RTT y ancho de banda máximo disponible entre los dos extremos, teniendo en cuenta que, a mayor RTT, mayor deberá ser la ventana para alcanzar una determinada velocidad de descarga, pues se tiene que:

(tal y como sucedía en nuestro símil de la cinta transportadora)

Para comprobar el impacto que esta limitación puede tener en un test de velocidad, consideremos el caso de un usuario con Windows XP que quiere comprobar la velocidad de su nuevo acceso xDSL de 30 Mbps usando un medidor de velocidad. Si tenemos en cuenta que la ventana máxima por defecto en Windows XP es de 64 KBytes y tomamos como referencia los RTT hacia algunos de los tests de velocidad más populares en España (por ejemplo, con un ping…), podemos elaborar una tabla como la siguiente, haciendo una simple división:

Así, tendríamos que si nuestro usuario utilizase el Test A para medir su velocidad, acabaría descubriendo alarmado que éste le estima prácticamente la misma velocidad que si tuviera un ADSL convencional, y comenzaría a preguntarse por qué ha contratado una conexión de alta capacidad si sigue recibiendo lo mismo… Algo parecido le sucedería si probara con el Test C durante la noche, ya que apenas le estimaría 9 Mbps.

Si, finalmente, nuestro usuario descubriera los tests B o D, o una mañana repitiera las pruebas con C, seguiría pensando que el servicio es deficiente (apenas da un 70% de la velocidad contratada), pero que “al menos se están esforzando en mejorarlo…” Al mismo tiempo, el usuario descubre extrañado cómo aplicaciones que utilizan más de una conexión TCP al mismo tiempo (p.e. programas de P2P) son capaces de alcanzar velocidades de descarga mucho mayores…

Ni qué decir tiene que si uno de estos tests de velocidad recopilara los resultados de todas sus medidas e hiciera un estudio sobre la velocidad de la banda ancha, podría llegar a la conclusión de que, cuanto mayores son las capacidades de los accesos, peor es el cumplimiento de la velocidad contratada… sin que este hecho llegara a detectarse nunca por las operadoras ni por los propios usuarios en condiciones normales de uso (p.e. utilizando aplicaciones multi-conexión).

¿Y qué pasaría si los usuarios fueran actualizando sus sistemas operativos o se las arreglaran para cambiar la configuración de su pila TCP para hacerla más eficiente? Pues que aún habría que comprobar si la ventana del servidor del test de velocidad es suficiente para estimar altas velocidades. Así, si añadimos a la tabla anterior una estimación indirecta de la ventana máxima de cada emisor, podremos estimar la máxima velocidad que puede medirse en cada caso:

Como puede apreciarse, el Test A seguiría infraestimando la capacidad de los accesos de banda ancha, mientras que los tests B y C andarían muy cerca de los límites de las ofertas más avanzadas de acceso. Sólo el Test D parece tener una configuración holgada de TCP.

Por último, cabría destacar que la notable diferencia en el RTT del Test C entre la mañana y la tarde-noche podría ser un indicador de problemas de saturación en el propio acceso del medidor de velocidad, pues, como puede apreciarse en la siguiente figura, los períodos de más RTT coinciden además con intervalos de abundantes pérdidas de paquetes (representadas en azul):

Una vez analizada la influencia de la configuración de ventana máxima en los extremos de la medida, dedicaremos el próximo post al estudio del otro gran elemento perturbador de estos tests: el crecimiento gradual de la ventana.

ENTRADAS DE ESTA SERIE:

1. La importancia de una estimación precisa.
2. ¿Cómo funciona un test de velocidad?
3. TCP, la empresa de paquetería.
4. Las limitaciones de la ventana (o cómo el sistema operativo sabotea nuestra medida).
5. El crecimiento gradual de la ventana (o cómo el fichero de descarga se nos queda pequeño).

Como vimos en el post anterior, los test de velocidad actuales consisten en la descarga de un contenido de tamaño conocido a través de una conexión TCP y la medición del tiempo empleado para completar la transferencia. Sin embargo, como ya adelantábamos, la influencia del protocolo TCP en la velocidad de descarga puede ser significativa en determinados casos y, en particular, cuando se trabaja con conexiones de alta capacidad.

Para comprender mejor las limitaciones que TCP impone a un test de velocidad, nos valdremos aquí de una analogía sencilla que nos permita analizar intuitivamente los factores que condicionan este tipo de transmisiones.

Supongamos una empresa de paquetería cuyo único cometido es transportar de forma fiable paquetes postales de un edificio a otro. Para ello, se vale de una cinta transportadora “de alta velocidad” que, en un recorrido circular —similar al de las cintas de equipaje de los aeropuertos—, va y vuelve entre los dos edificios.

Para llevar a cabo esta tarea con éxito, la empresa dispone de dos trabajadores, cada uno emplazado en un extremo, de manera que el primero (el “emisor”) se encargaría de depositar los paquetes por orden en la cinta, y el otro (el “receptor”) se encargaría de recogerlos en el otro extremo y pegar un post-it en su lugar, para que llegue a su compañero a modo de acuse de recibo, aprovechando así que la cinta es circular. De esta forma, en caso de que alguno de los paquetes se perdiera por el camino (cosas que pasan…), el “emisor” estaría en disposición de ensamblar otro paquete idéntico al extraviado y volverlo a poner sobre la cinta (como veis, se trata de una empresa de paquetería con habilidades sorprendentes).

En estas circunstancias cabe preguntarse: ¿cómo podrían coordinarse los dos extremos para aprovechar al máximo la velocidad de la cinta (es decir, para enviar el máximo número posible de paquetes por hora) a la vez que garantizan una entrega fiable?

Una forma posible de organizar estos envíos sería que el “emisor” enviase un paquete y esperase a la recepción del correspondiente acuse de recibo para poner el siguiente en la cinta (o, en su defecto, esperase un tiempo prudencial antes de reenviar el paquete presumiblemente “extraviado”). Sin embargo, si la distancia entre ambos edificios fuera considerable, con esta operativa no conseguiríamos aprovechar la capacidad de transporte de la cinta transportadora, toda vez que, a lo sumo, estaríamos introduciendo un paquete por cada vuelta completa de la cinta, de manera que casi toda su superficie de transporte quedaría desocupada.

Para mejorar la eficiencia de este proceso, en lugar de depositar un solo paquete en la cinta y esperar su acuse de recibo para cargar el siguiente, la empresa de paquetería decide que puedan cargarse 2 paquetes sin que se haya recibido aún su confirmación y, una vez se reciba el acuse de recibo del primero, se vuelva a depositar un nuevo paquete en la cinta, de manera que vuelva a haber 2 paquetes “en circulación”, y así sucesivamente. Una vez que la empresa descubre que, con esta sencilla medida, ha conseguido doblar el número de paquetes que era capaz de transportar en una hora, decide ir aumentando gradualmente este número de paquetes “en circulación”, de manera que a la semana siguiente se pasa de 2 a 4, la siguiente de 4 a 8, y así sucesivamente. De esta forma, cada semana la empresa consigue doblar su capacidad de transporte… hasta que llega a trabajar con un número tan grande de paquetes “en circulación” que consigue llenar completamente el espacio de la cinta (al menos, en su camino de ida). Una vez alcanzado este punto de “saturación”, la empresa entiende que está aprovechando al máximo la velocidad de la cinta transportadora pues, por cada paquete que se esté introduciendo en un extremo, la cinta estará entregando otro al receptor, y éste, a su vez, estará colocando un nuevo acuse de recibo que, más adelante, provocará que se deposite un nuevo paquete al ritmo adecuado… En estas condiciones de funcionamiento, nos encontramos con que:

• El sistema está trabajando de forma óptima, y la única forma de aumentar el ritmo al que se transportan paquetes pasa por aumentar la velocidad de la cinta.
• En caso de que algún día aumentara la longitud de la cinta transportadora (porque hubiera que enviar paquetes a un edificio más lejano) sería necesario un nuevo aumento de los paquetes “en circulación” para volver alcanzar la máxima eficiencia.

Como ya habrá deducido el lector, en el caso de un protocolo de transporte como TCP las cosas funcionan de una forma muy parecida:

• La velocidad de la cinta transportadora equivale al ancho de banda disponible.
• Los paquetes postales que viajaban por la cinta son ahora paquetes de información que se transmiten por la red.
• Los dos trabajadores que se ocupaban de cargar y descargar paquetes al ritmo adecuado son ahora los dos extremos del protocolo TCP (el emisor y el receptor, respectivamente).
• Así mismo, el papel que jugaban los post-it que se depositaban en la cinta lo desempeñan ahora paquetes especiales de asentimiento, ACK, que envía el receptor al emisor para ir confirmando la correcta recepción de paquetes de datos.
• La longitud de la cinta (dependiente de la distancia entre los edificios) equivale aquí al RTT, que es el tiempo necesario para transportar un paquete de un extremo a otro y que llegue su correspondiente ACK de vuelta.
• El número máximo de paquetes “en circulación” se denomina en TCP “ventana” y, al igual que sucedía en el ejemplo anterior, es un parámetro fundamental para su correcto funcionamiento con altas velocidades.
• El tanteo inicial de la empresa hasta encontrar un número adecuado de paquetes “en circulación”, equivale a un procedimiento análogo al que existe en TCP, denominado slow start, por el que se va aumentando gradualmente la ventana (y, con ella, el caudal de la conexión) hasta detectar una situación de saturación.

En definitiva, al igual que sucedía en el ejemplo anterior, nos encontramos con que es necesario que el parámetro de ventana sea el adecuado para que, en las condiciones de RTT que haya en cada momento, TCP pueda aprovechar al máximo el ancho de banda disponible. Así mismo, nos encontramos con que, a causa de este proceso inicial de “tanteo”, la conexión no alcanza su máximo caudal hasta que no ha transcurrido un cierto tiempo, tanto mayor cuanto mayor sea la velocidad máxima que puede alcanzarse en la línea.

Como puede intuirse fácilmente, el impacto que estos dos fenómenos tienen en el resultado del test puede llegar a ser muy relevante a altas velocidades. A analizar estas implicaciones y los efectos que provocan en algunos de los tests de velocidad más populares, dedicaremos las próximas entregas.

ENTRADAS DE ESTA SERIE:

1. La importancia de una estimación precisa.
2. ¿Cómo funciona un test de velocidad?
3. TCP, la empresa de paquetería.
4. Las limitaciones de la ventana (o cómo el sistema operativo sabotea nuestra medida).
5. El crecimiento gradual de la ventana (o cómo el fichero de descarga se nos queda pequeño).

Los tests de velocidad actuales, por razones de simplicidad, basan su estimación en medir el tiempo que el usuario necesita para descargar un contenido de tamaño conocido a través de una conexión TCP. Así, dividiendo el tamaño del contenido por el tiempo invertido en su descarga, se determina el caudal medio que tuvo esa conexión y este valor se emplea como estimador del ancho de banda disponible en el acceso del usuario. Para facilitar la realización del test, el proceso de descarga se oculta al usuario tras una interfaz sencilla (en flash o java), que sirve luego para presentar los resultados de la prueba de una manera amigable.

Una variante de esta metodología es la del llamado “test de Ookla”, donde se toman numerosas muestras a lo largo de la descarga (contando los bytes transferidos en cada intervalo), se descartan muestras “extrañas”, y al final se hace un promedio de todas esas estimaciones parciales. Esta variante, que permite ir ofreciendo al internauta “resultados intermedios” a modo de velocímetro, es la que emplean gran parte de las webs españolas que ofrecen medidores de velocidad.

Hay que señalar que estas metodologías se centran, por tanto, en estimar el ancho de banda que “llega” a la aplicación y no el realmente provisto por la red (que incluiría el transporte de todas las cabeceras de enlace, de IP, de TCP, etc.). Si bien la diferencia entre ambas magnitudes puede llegar a ser de algunos puntos porcentuales, como primera aproximación suele considerarse ésta una fuente de error “controlada”, ya que es de un orden de magnitud relativamente modesto y, casi siempre, es constante en porcentaje respecto a la capacidad del acceso que se quiera medir. Sin embargo, para que lo anterior sea cierto, es necesario garantizar que el usuario no está utilizando ninguna otra aplicación durante la realización de la prueba (por ejemplo, descargándose un fichero al mismo tiempo). Esta condición será especialmente difícil de verificar completamente si se trata de un test de velocidad accesible al gran público a través de Internet.

No obstante, la principal fuente de error en tests basados en esta metodología procede del impacto que el propio protocolo TCP y sus mecanismos de control de flujo tienen en la velocidad de descarga cuando la red de acceso es de alta capacidad. Así, factores como la configuración de TCP en el servidor de medidas y en el ordenador del usuario, la latencia entre ambos extremos o el tamaño de la descarga pueden tener un impacto determinante en el máximo caudal que puede alcanzarse en la conexión TCP de la prueba y, por tanto, en la velocidad que finalmente se estima para ese acceso.

Teniendo en cuenta la importancia de estos factores como principales fuentes de error en los tests de velocidad más populares, merecerá la pena revisarlos con más atención para entender cómo TCP puede llegar a comportarse de forma imprevista. A revisar el comportamiento de este protocolo y a señalar sus limitaciones para un test de velocidad, dedicaremos el próximo post. Para ello nos valdremos de un símil sencillo con una empresa de paquetería empeñada en aprovechar al máximo su nueva cinta transportadora “de alta velocidad”.

ENTRADAS DE ESTA SERIE:

1. La importancia de una estimación precisa.
2. ¿Cómo funciona un test de velocidad?
3. TCP, la empresa de paquetería.
4. Las limitaciones de la ventana (o cómo el sistema operativo sabotea nuestra medida).
5. El crecimiento gradual de la ventana (o cómo el fichero de descarga se nos queda pequeño).

La medición de la velocidad efectiva de los accesos de banda ancha ha pasado, en un breve espacio de tiempo, de ser un tema propio de foros especializados de Internet a convertirse en noticia destacada en los medios de comunicación más importantes.

Por un lado, la reciente iniciativa del Ministerio de Industria para que los proveedores de acceso proporcionen, al menos, un 80% de la velocidad ofertada parece fijar un umbral de referencia para los usuarios, a la vez que supone un reto para las operadoras, que habrían de “examinarse” de acuerdo a este criterio con cada nueva modalidad de acceso que ofrezcan. En este sentido, la existencia de tests de velocidad que estimen correctamente el ancho de banda disponible en las nuevas modalidades de acceso aparece como un requisito fundamental para que esta iniciativa sea útil para todos los agentes y redunde, finalmente, en una mejora del servicio.

Por otro lado, los medios de comunicación se han hecho eco recientemente de los resultados de algunos estudios de velocidad basados en conocidos tests gratuitos, en los que llama la atención que sean precisamente las modalidades de mayor capacidad las que parecen alejarse más de sus valores nominales. Titulares como “Ninguna oferta de ADSL de 10 ó 20 megas llega al 80% de velocidad real” o “Las ofertas de ADSL de 20 megas en España se quedan en un tercio de lo anunciado” subrayan la importante divergencia en los accesos de alta capacidad entre los resultados de los tests y los valores nominales ofertados. En el texto de estas noticias, también se hace notar que, curiosamente, sea cual sea el operador o la modalidad de alta capacidad que se considere (10 ó 20 Mbps), la velocidad siempre parece encontrarse en torno a los 7 Mbps. En esta situación el lector podría preguntarse, ¿cómo es posible que todas las operadoras parezcan desviarse de la misma manera (y en la misma magnitud) en sus modalidades de acceso de gama más alta, y acaben sirviendo exactamente el mismo ancho de banda? ¿Existe alguna limitación tecnológica en estas dos modalidades de acceso que les impida alcanzar velocidades más altas? ¿Cuántas muestras del estudio llegaron a sobrepasar los 7 Mbps?

La repercusión de todas estas noticias no hace sino subrayar el importante papel que estos tests de velocidad pueden jugar en el futuro, y cómo éste será todavía más relevante con la aparición de nuevas modalidades de acceso con aún más capacidad, donde las exigencias para el medidor pueden ser máximas.

En próximos posts, analizaremos el funcionamiento básico de un medidor de velocidad y explicaremos de forma sencilla cuáles son los principales factores que limitan sus estimaciones, fundamentalmente cuando trabajan con accesos de gran ancho de banda. Así mismo, evaluaremos el rendimiento que son capaces de ofrecer algunos de los tests de velocidad más populares en España.

ENTRADAS DE ESTA SERIE:

1. La importancia de una estimación precisa.
2. ¿Cómo funciona un test de velocidad?
3. TCP, la empresa de paquetería.
4. Las limitaciones de la ventana (o cómo el sistema operativo sabotea nuestra medida).
5. El crecimiento gradual de la ventana (o cómo el fichero de descarga se nos queda pequeño).

El llamado "peak oil" es un término que irá ganando en popularidad -para nuestra desgracia- en los próximos años. Se refiere al punto culminante de producción de petróleo y otros combustibles fósiles y supondrá, ahora sí, un punto de inflexión en nuestra forma de gestionar y consumir energía, por que una vez se haya alcanzado el máximo, ya no habrá vuelta atrás en un declive en la producción que nos obligará a tomar medidas sin dilación.

En teoría todas las materias primas pueden verse abocadas en algún momento a un "peak" que refleje el máximo de producción a partir del cual ésta caerá progresivamente. Lógicamente hay materiales más propensos a estos fenómenos (platino, cobre, fósforo, uranio, recursos pesqueros) que otros (hierro, níquel). Es razonable suponer que conociendo el momento aproximado en el que puede suceder ese máximo de producción, se adopten medidas para buscar alternativas al declive de la materia prima afectada. Sin embargo no es así, la primera predicción de "peak oil" conocida, la referida a la extracción de petróleo en Estados Unidos, pasó desapercibida, en su tiempo (1971). El momento en el que ocurrirá (o ha ocurrido) el más preocupante máximo mundial, es objeto de continuos debates.

Aunque sea difícil reconocerlo así, Internet, o la conectividad en amplio sentido, es una de las materias primas en las que se basa el desarrollo del mundo actual, es uno de los pilares de ese mundo "plano" de Friedman. ¿Es previsible una escasez de esta "materia prima"?

Aunque la capacidad mundial de conectividad, tanto de voz como sobre todo de datos, no deja de crecer, la presión desde el lado de la demanda es un monstruo voraz.

El tráfico en Internet ha estado creciendo a cotas muy altas en los últimos diez años, aunque las cifras de crecimiento se ha moderado últimamente: así, se ha pasado de doblarse cada 100 días a mediados de los 90, a crecer anualmente entre un 50 y 60% en 2007. Hay una cierta reducción en el crecimiento, pero es crecimiento al fin y al cabo.

El crecimiento del uso de video en Internet (ahora mismo un 20% del tráfico), la inminencia de la alta definición, con el consiguiente crecimiento de tráfico, y la explosión de los UGC (User Generated Contents, o contenidos generados por el usuario) están disparando alarmas ante la inminencia de otro "peak": el de capacidad de la red.

Se calcula que, por ejemplo, cada minuto, se añaden 8 horas de vídeo en un servicio como Youtube. Todo ello define lo que algunos llaman un "exaflood", o la inundación de exabytes de información en la red. Para IDC se pasaría de 161 exabytes generados en 2006 a 988 en 2010; para CISCO, el tráfico se quintuplicará entre 2006 y 2011; AT&T habla de un 80% tráfico debido al vídeo en 2010, comparado con el 30% actual.

Lo cierto es que se es la infraestructura crece, pero no al mismo ritmo: teóricamente, la capacidad aumentó un 47% en 2006, aunque el tráfico lo hizo un 75%. Durante estos últimos años hemos ido consumiendo la sobrecapacidad creada en los tiempos de la "burbuja de Internet": kilómetros y kilómetros de fibra instalados en tiempos de optimismo, que han tenido una importancia decisiva en el actual periodo de esplendor de la red.

Está claro que la solución vendrá del crecimiento de las infraestructuras, pero ese hecho también causa fricción. Los servicios Web eran hasta ahora más equilibrados en su consumo de recursos, y las tarifas planas se han diseñado pensando en ellos. La irrupción del servicio iPlayer de la BBC ha hecho que algunos ISPs se hayan puesto en pie de guerra. Youtube, y los servicios proveedores de vídeo a la carta son ávidos devoradores de ancho de banda, pero nadie parece dispuesto a pagar más por el consumo de vídeo. Los propietarios de estas infraestructuras se lamentan de que en este nuevo escenario resulta difícil mantener el ritmo de inversión necesario, y al mismo tiempo rentabilizarla; los gobiernos no parecen haberse dado por aludidos, pero la industria tampoco clama por su intervención; las soluciones en torno a la "net neutrality" (o su ausencia) que implicarían discriminar el tráfico según su tipo y origen, generan debates ásperos.

Dicho todo lo anterior, no hay que olvidar que una constante universal es la predicción de inminentes desastres. La visión pesimista del momento presente, y el anuncio de inevitables y próximos desastres se ha sucedido siglo tras siglo: en la Roma de los Flavios, la España de Carlos V, o los Estados Unidos desde los años 60, se han realizados predicciones de declives inminentes, y decadencias para pasado mañana.Viendo la aparente avidez de noticias de desgracias que den la razón a quienes las pronostican, no está de más tomar estas predicciones con prudencia y sentido crítico, y evitar dejarse arrastrar sin resistencia por ellas. Es por ello, que hay también una corriente de opinión, menos publicitada, que se muestra confiada en que la reducción de crecimiento de tráfico baste para el despliegue de nuevas infraestructuras. Incluso se propone la vuelta a arquitecturas centralizadas más eficientes que la actual distribución de servicios y, sobre todo, contenidos. "Una única copia" de cada contenido y universalmente accesible, frente a millones de clones en cada servidor y en cada hogar.

Un debate que nos va a mantener entretenidos un buen tiempo.

Citando a:

• La Cofa ("El universo (digital) se expande más rápido de lo que se pensaba", "Más ancho de banda, más velocidad,… ¿hasta cuánto?", y "Tecnologías básicas para el final de una década: predicciones, tendencias y pronósticos")
• New Scientist ("Will the internet ever peak?")
• Ars Technica ("Keeping pace? Torrents of traffic and the Internet backbone", y "The coming exaflood, and why it won’t drown the Internet")
• C|Net ("AT&T: Internet to hit full capacity by 2010")
• IDC ("The Diverse and Exploding Digital Universe")
• Computing ("Tiscali and BBC quarrel over iPlayer")