Green Networking

Hace un par de semanas participé en el workshop Energy Efficiency and Networking organizado por el IMDEA Networks, donde varios (brillantes) investigadores presentaron sus trabajos/ideas sobre el presente y futuro del tan cacareado "Green Networking". La verdad es que este tema es interesantísimo y dará mucho "juego" a los investigadores, aunque me queda la duda del impacto real que puedan tener estas propuestas a la hora de rebajar las emisiones de CO2.

Una cifra demoledora que se comentó en el workshop, es que hoy en día el gasto energético de las TIC (Tecnologías de la Información y Comunicaciones) es comparable con el del sector aeronáutico, y las estimaciones es que siga subiendo. Como era de suponer, el gran "vampiro eléctrico" son las granjas de servidores que representan casi la mitad de ese gasto (las cifras bailan un poco, dependiendo de la fuente). Las redes de transmisión tampoco se quedan atrás, representando sobre un 26% del gasto total de las TIC (otra vez, depende de la fuente). Por ejemplo, un dato que da mucho que pensar es el del consumo de las redes Ethernet, en donde este crece de forma exponencial según aumentamos el rate de la tarjeta... y todo esto en modo idle, es decir, ¡¡¡sin enviar ni recibir, sólo por estar activa!!!.

Para mitigar el problema de consumo de Ethernet, por ejemplo, ECMA International ha publicado un estándar conocido como proxZzzy (chulo el nombre) en donde sitúan un proxy en medio de uno o varios equipos y el resto de Internet. Cuando un equipo detecta un estado idle, se lo comunica al proxy y se va a "dormir" (modo de bajo consumo). El proxy detectará paquetes destinados al "PC durmiente" y lo despertará si es necesario.

Algunos son pesimistas. Se dice que la reducción del consumo energético será marginal y cara, por lo que muchos fabricantes y/o proveedores de servicio no los adoptarán. De todos modos, esto es algo que aún está comenzando y hay mucho campo para seguir investigando. Yo por mi parte, ya he puesto un par de PFCs sobre el tema, a ver si contribuímos a pintar de verde nuestras redes :-)

P2P video caching

Han pasado más de dos años desde mi última entrada, así que ahora me dedicaré a escribir entradas cortas, para intentar escribir más cosas que se me ocurren.

Ahora mismo estamos trabajando en P2P video caching (PVC). ¿Cuál es la idea detrás del PVC? Bueno, es algo parecido a tener un cliente estilo BitTorrent para YouTube. Sería algo así como tener los contenidos (vídeos) en los propios equipos de los usuarios una vez se los descargan.

Algunos dirán que esto es precisamente lo que hace BitTorrent. Sí, pero con una pequeña diferencia. En BitTorrent el usuario decide mover, borrar o copiar el fichero, mientras que en PVC el usuario "reserva" espacio en su disco para hacer cache (guardar y reemplazar) de los videos que baja, pero que él en principio no volverá a ver (y si quiere volver a verlos, sólo tiene que acceder a su cache).

Existen varios problemas a los que nos estamos enfrentando. El primero de ellos, y el más gordo, es cómo poder simular el comportamiento de usuarios para elegir, descargar y visualizar los videos. Es decir, simular el acceso en YouTube. Actualmente tenemos un crawler de YouTube, que obtiene los vídeos más recientes cada 15 minutos y luego, también con 15 minutos de intervalo, se dedica a capturar el número de vistas totales de cada uno de los vídeos que tenemos almacenados. Esto lo estamos haciendo con la API de YouTube que nos está dando varios problemas, ya que devuelve varios errores (no los culpo, ahora mismo llevamos una semana y unos 30,000 vídeos).

Una vez tengamos datos realistas de YouTube, lo siguiente será diseñar una arquitectura que funcione bien de forma descentralizada. Tenemos que contestar las siguientes dudas:

• ¿Qué pasa si el usuario tiene la cache llena? Tendremos que borrar ficheros antiguos, pero igual los antiguos son muy populares.
• ¿Es bueno guardar el fichero que estamos bajando? A lo mejor varios usuarios ya tienen ese vídeo.
• ¿Cómo localizamos el contenido? ¿Bootstrap server? ¿Método gossip (inundación)?
• ¿Cómo afecta el churn (entradas y salidas de usuarios al sistema)? Un usuario que sale del sistema "se lleva" su cache. ¿Y si las copias que dicho usuario tenía eran las únicas en el sistema?
• ¿Qué pasa cuando un contenido se vuelve popular/impopular? ¿Existen suficientes/demasiadas copias en el sistema?

Queda mucho por hacer, pero ya iré poniendo resultados de esta investigación.