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

Ya hemos hablado desde este mismo blog otras veces del “controvertido” twitter, el servicio lanzado hace ya dos años que permite a sus usuarios enviar mensajes de sólo texto, con una longitud máxima de 140 caracteres haciendo posible el “lifestreaming”.

Recientemente The Cocktail Analysis ha publicado un estudio sobre sus usuarios (que por cierto, sigue en construcción a través de una wiki) y la verdad es que, a la luz de los datos, puede decirse que se trata de un servicio para geeks.

El retrato robot de sus usuarios es varón (75%), de entre 21 y 30 años (56%), bloguero (83%) ,vinculado al mundo de Internet y las nuevas tecnologías (72%) y  que utiliza la herramienta por interés profesional (52%).

Me llama la atención el alto nivel de satisfacción con la experiencia de uso; el 93% de los usuarios se declara satisfecho y además es relevante el hecho de que los usuarios vayan incrementando paulatinamente la frecuencia con la que usan la aplicación (se “pican”); cerca de la mitad (47%) de los usuarios que tienen al menos dos meses de antigüedad confirma que ahora la utiliza con más asiduidad que antes, frente al 17% que en estos momentos habría disminuido la intensidad de uso.
Twitter muestra un carácter envolvente: el 73% de los usuarios se acerca a la aplicación varias veces al día, desde casa el 99%, en la oficina el 79%, desde el centro de estudios el 52% o en la calle el 54%. Y por lo tanto esto conlleva un fuerte uso en movilidad: el 40% se conectan desde un teléfono móvil o el smartphone y el 23% de los mensajes (updates) que éstos publican se envían desde un dispositivo móvil. El 18% mandan más de la mitad de sus mensajes a través de este canal.

Los dispositivos desde los que se utiliza el servicio son muy importantes, claro está. Me ha llamado la atención que entre los tres terminales móviles más usados, el primero sea el iPhone, pero es curioso que este dispositivo no estuviera todavía comercializado en las zonas donde se realió el estudio (algunos países de latinoamérica y España) en el momento en el éste se realizó. Sin duda eso habla mucho del perfil de sus usuarios.

Pero, ¿para qué usa la gente el twitter?:

• Para poner en común cosas que se descubren mientras se navega por la red (41%)
• Para comunicar noticias o temas que se estiman de interés colectivo (40%)
• Para poner links de Webs (38%)
• Para socializar estados de ánimo (38%)
• Para comentar lo que dicen personas a las que se sigue (30%).
• Y sólo el 9% de los encuestados utiliza a menudo los mensajes privados (en este caso los usarios siguen prefiriendo la mensajería instantánea)

Y ¿qué les hizo empezar a usarlo?

• Mantenerse informado de lo que está haciendo el círculo de amigos y conocidos  el 69% (¿quién no querría ponerle un twitter a su hijo?)
• y en segundo lugar para entretenerse ( el 63%)

Sin duda, toda una herramienta para la socialización (eso sí, de momento, entre geeks).

Si tienes la suerte de disfrutar de un nuevo iPhone 3G, habrás notado que la duración de la batería es un serio problema. Un móvil hiper-multimedia, con GPS, capacidad de ejecutar todo tipo de aplicaciones y juegos, que te lo llevas de viaje a donde quiera que vayas, diseñado para ser usado continuamente, debería tener una autonomía mucho mayor. ¿Te imaginas llenar el depósito de gasolina del coche cada 5 ó 6 horas de conducción?

La buena noticia es que el iPhone es mejor en duración de batería que otros teléfonos de la competencia. Pero, al igual que pasa con los portátiles, la duración de las baterías sigue siendo uno de los retos tecnológicos más importantes para los investigadores.

Intel ha anunciado su próxima arquitectura Nehalem en la reciente conferencia Intel Development Forum (IDF). Están esforzándose en el diseño de chips más rápidos aunque de mucho menor consumo que los actuales. También han presentado una nueva tecnología Wireless Energy Resonant Link, para la transmisión inalámbrica de energía eléctrica mediante campos magnéticos que no son perjudiciales para la salud.

vídeo: Intel CTO: No more power cords

Los ingenieros del MIT investigan la creación de micro-baterías del tamaño de una célula, diseñadas para su uso en microdispositivos electrónicos y ensambladas mediante el virus M13. La responsable del laboratorio de materiales que lleva a cabo esta investigación es Angela Belcher, experta en biomateriales, materiales biomoleculares, interfaces orgánicos-inorgánicos y química de estado sólido. Junto con Yet-Ming Chiang y Paula Hammond, ha publicado sus avances científicos en Proceedings of the National Academy of Sciences.

Si hay algo que parece difícil de entender es el continuo fracaso de diferentes compañías a la hora de traer Internet a la televisión. Sobre todo cuando las estadísticas nos dicen que una gran cantidad de gente utiliza el ordenador para visionar películas (lo cual no parece lo más lógico) y también en muchos casos los internautas suelen ver la televisión a la vez que utilizan el ordenador como informa un reciente estudio realizado en el Reino Unido.

Sin duda problemas de usabilidad en la navegación, necesidad de un set-top-box…, al final han mandado al traste muchos de los intentos que se han producido.

Parece muy interesante la idea de Yahoo e Intel de al menos esquivar el primer motivo, la usabilidad en la navegación, gracias a la idea novedosa de acceder a Internet desde la televisión utilizando Widgets (pequeñas aplicaciones que permiten el acceso a una información concreta de Internet sin apenas necesidad de navegar). De esta manera no sería difícil acceder a una aplicación concreta utilizando el mando a distancia de la televisión.

La idea de Yahoo consiste en la creación de un Widget Channel que permitiría a los desarrolladores crear pequeñas widgets que se mostrarían en una barra en el fondo de la pantalla de televisión. Estos widget permitirían acceso directo a aplicaciones, desde chequear el twitter hasta ver una película.

Varias empresas se han unido al proyecto como Intel que proveerá un microprocesador especial para este fin, Toshiba y Samsung se han ofrecido a integrarlo en sus televisiones y Comcast a ofrecer contenidos.

En fin, un intento más que se espera llegue al mercado a mediados de 2009. Habrá que esperar y ver si esta vez es la definitiva.  

Fue Amazon una de las empresas más pioneras en lanzar servicios ”Cloud Computing” de una forma comercial. Su servicio EC2 (Elastic Compute cloud) de hecho se ha convertido en la referencia general como modelo de empresa que abre su infraestructura a terceros y la ofrece como un servicio más.

Después se le han seguido otras empresas como Google y su APP Engine, IBM, … de lo que hemos ido informando en este mismo blog. Hasta alguna empresa (Dell) ha andado avispada y ha intentado patentar el nombre “Cloud Computing”, lo cual ha sido rechazado de plano por los organismos competentes.

Pues bien Amazon ha dado un paso más al lanzar un servicio de almacenamiento permanente como un servicio “cloud” más y que acaba de ser  comercializado con el nombre de Elastic Block Store (EBS). Es importante destacar el carácter permanente de la información, ya que hasta ahora su servicio EC2 no permitía realizar un almacenamiento permanente y cuando se finalizaba la instancia se perdían los datos. Con el nuevo servicio el cliente es como si tuviera un disco duro personal y hasta podría formatearlo si lo deseara.

Como los anteriores servicios de Amazon se trata de un servicio de pago cuyo coste es de 10 céntimos por GB por mes y 10 céntimos por millón de I/O. Como ejemplo, una empresa que almacene de esta manera 100 GB y soporte 100 I/O por segundo, debería pagar 36$ al mes.

Sin entrar en cuestiones de seguridad y privacidad que seguro echarán a más de una compañía atrás, la conveniencia o no dependerá de la estructura de costes de la empresa y parece que los precios son más que aceptables. Pensemos en los costes de adquisición y mantenimiento de Hw y Sw, conexión a Internet que permita un elevado tráfico, energía … y hagamos las cuentas.

Mientras Viviane Reding prosigue en su lucha para separar las redes de los servicios de telecomunicaciones, en Africa se adelantan con una nueva política para reestructurar el mercado de las telecomunicaciones.

El Ministerio de Información y Comunicación de Ghana ha anunciado que los operadores y proveedores de servicios podrán obtener licencias según un nuevo marco simplificado y unificado. Con esto se evitará la multiplicidad de licencias para cada tipo de tecnología existente, como ocurre en la actualidad (telefonía fija, móvil, ISP, satélite, etc.).

Las tres nuevas categorías de licencias son:

• Network Facilities Providers (NFP), para los operadores que tienen una infraestructura de red independientemente de su tecnología (satélite, radio, móvil, fija, etc.).
• Applications service provider (ASP), para los proveedores de servicios dirigidos a usuarios finales y basados en los servicios de red ofrecidos por otro proveedor (NFP).
• Content Service Provider (CSP), para los proveedores de contenidos, información y servicios de procesamiento de datos.

¿Es este un ejemplo aplicable al mercado europeo de las telecomunicaciones? Lo que pretende el gobierno de Ghana es acelerar el desarrollo tecnológico de su país eliminando las trabas burocráticas (coste de múltiples licencias) para dar entrada a nuevos operadores.

Vía id4online.

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).

Periódico saneamiento de memoria. Una lista de artículos interesantes que corren el peligro de caer en el olvido:

1. Parece un avance extraordinario que habrá que seguir de cerca: “Jajah Launches Instant Chinese/English Voice Translation” enTechCrunch . Un traductor automático y vocal de chino a inglés en tiempo real.
2. EL futuro de los navegadores a través de los nuevos diseños conceptuales de Mozilla: “Mozilla mocks up possible Firefox successors in idea factory” en Ars Technica, “Mozilla Scenarios” en Open the Future, “Introducing the Concept Series; Call for Participation” en Mozilla Labs, y “Snowl, Aurora, OAuth, OpenId y el futuro del navegador web” en Error500.
3. Las novedades duran poco. Hace nada se abría la posibilidad a realizar llamadas desde el móvil en vuelos comerciales, ahora Delta anuncia conectividad WiFi en sus aviones: “Delta to Become Only Major U.S. Airline to Offer Broadband Wi-Fi Access on Entire Domestic Mainline Fleet” en Delta News, y “Delta will be first airline to offer WiFi on all US flights” en Ars Technica.
4. Fire Eagle de Yahoo, que vimos en el ETech y describimos aquí (“ETech: segundo día“) ya está en Beta pública. Se trata de un movimiento muy importante para Yahoo! y un gran impluso para las aplicaciones geográficas. Más en “Yahoo! Launches Fire Eagle” en Yahoo!, y “Yahoo Fire Eagle en abierto” en Error500.
5. “The State of the Global Telecosm” en Technology Review, un artículo muy recomendable para pulsar el estado de esta industria en este año que se dirige rápidamente a su final.
6. Microsoft no se puede estar quieta:continúa con sus experiencias de evolución de interfaces (“Microsoft Surface Sphere, evolución del concepto“, en Xataka) o aporta financiación a la ¡Apache Foundation! (“Microsoft to sponsor the Apache Software Foundation” en Ars Technica). Si queda alguien con ganas de colaborar con ellos, Don Doge explica cómo: “How to partner with Microsoft” en The Next Big Thing.
7. Descubro la serie “in Plain English” de Commoncraft gracias a “El social media y la metáfora de los helados” en el Blog Salmón. Videos cortos, ilustrativos y divertidos de todo tipo de conceptos, con especial atención a los de la Web 2.0. Por ejemplo, aquí tenemos el “Social Networking”:
   
8. Capítulo de predicciones. Para Jupiter, en 2012, un cuarto de la población del planeta está conectada, y lo que es mejor, podrán entenderse entre ellos gracias nuevos sistemas de traducción automática, como los de Weaver, Apptek e IBM. Más en “A quarter of planet to be online by 2012, and able to understand each’s other’s language” en KurzweilAI.
9. “Marc Fleury and Home Automation” en O’Reilly Radar. El creador de JBoss está ahora tras OpenRemote, una iniciativa crear un middleware para la automatización del hogar que cuenta ya, entre otros componentes, con un interface para gestionar remotamente el hogar desde el iPhone.
10. Por último, BT compra Ribbit, una empresa de Silicon Valley que ofrece una plataforma de VoIP que permite usar desde el navegador Web nuestro número móvil para hacer y recibir llamadas, y realizar otras funciones exclusivas hasta ahora de la línea fija o móvil (gestionar el buzon de voz, …). “BT Buys Ribbit for $105 Million” en Gigaom, “Ribbit! The amphibian of telco voice platforms” y “Guest post: Why Ribbit is worth $105m to BT“, “DEMO 2008” en Mi otro blog, “Transforming Communication” en Technology Review

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).