Repositorio Institucional de Documentos

Caracterización y planificación del tráfico en una red Digital Signage TESIS DE FIN DE MÁSTER Autor: Jorge David de Hoz Diego Director: José Ruiz Mas Marzo 2013 Máster Universitario en Tecnologías de la Información y Comunicaciones en Redes Móviles Escuela de Ingeniería y Arquitectura Universidad de Zaragoza RESUMEN Este trabajo ofrece una visión general del funcionamiento de una red de Digital Signage actual y de la problemática que ha de hacer frente. Se describen los aspectos de funcionamiento que más repercusión tienen en el sistema, agilidad del mismo y su fiabilidad. Se definen qué aspectos son más importantes en la calidad de servicio experimentada por el usuario final o por el gestor de la red y se ofrecen propuestas para intentar mejorar estos aspectos desde el ámbito de la telemática con la tecnología existente actualmente. En primer lugar se aborda una breve descripción de la red de Digital Signage que es objeto de estudio y de los elementos involucrados en la misma. Se expone una descripción del cometido de cada uno de los dispositivos y del esquema de funcionamiento general. A continuación se detectan algunos de los problemas más relevantes existentes en dos ámbitos fundamentales. El primero hace referencia a los aspectos que están relacionados con la calidad de servicio en las comunicaciones entre los dispositivos de Digital Signage (players), su servidor central y el terminal del usuario o gestor de red. El segundo se centra en analizar exclusivamente el comportamiento players en entornos wireless. En ambos ámbitos se analizan las causas de los problemas detectados y se proponen soluciones. Algunas de ellas se implementan y se valoran los resultados obtenidos. Finalmente se plantean las conclusiones y se definen futuras líneas de acción. Índices Índices 7 ÍNDICE DE CONTENIDOS INDICE DE CONTENIDOS 3 INDICE DE FIGURAS 5 INDICE DE TABLAS 7 1. INTRODUCCIÓN 15 1.1. DESCRIPCIÓN DEL PROBLEMA 15 1.2. OBJETIVOS 16 1.3. ESTRUCTURA DE LA MEMORIA 16 2. ESTRUCTURA BÁSICA DE UNA RED DS Y SU FUNCIONAMIENTO 19 2.1. COMUNICACIÓN ENTRE EL SERVIDOR Y LOS PLAYERS 21 2.1.1. Conectividad con Internet 21 2.1.2. Establecimiento de las conexiones tuneladas 22 2.1.3. Servidor de Digital Signage: Gestión de conexiones 23 2.1.3.1. Monitorización de los players 24 2.1.3.2. Gestión de los players 24 2.1.3.3. Distribución de contenidos 26 3. QOS EN LA GESTIÓN DE LA RED 29 3.1. ASPECTOS MEJORABLES EN LA RED 29 3.1.1. Minimizar el tráfico de control 29 3.1.2. Sistema de distribución de contenidos en diferido 30 3.1.3. Diferenciación del tráfico 32 3.1.4. Optimización del protocolo SSH en comunicaciones tuneladas 33 3.2. MEJORA DE LA LATENCIA MEDIANTE EL CONTROL DE CONGESTIÓN 35 3.2.1. Herramientas para medir el Round-Trip delay Time (RTT) 35 3.2.1.1. Dtrace 36 3.2.1.2. Hping3 37 3.2.1.3. Tcpdump y tcptrace 37 3.2.1.4. Medida directa del RTT sobre mensajes echo tunelados 37 3.2.2. Impacto en la latencia del tráfico debido a los túneles que comparten sesión por multiplexación. 38 3.2.2.1. Metodología 38 3.2.2.2. Creación de los túneles 40 3.2.2.3. Ejecución de los clientes echo para obtener RTTs 40 3.2.2.4. Comparativa del RTT entre un túnel de sesión única y otro multiplexado con una conexión SFTP 42 3.2.2.5. Ajuste fino del tamaño de buffer de SFTP 44 3.2.2.6. Control de congestión con TCP Vegas 45 4. QOS CON ENLACES 802.11 51 4.1. DESCRIPCIÓN DE WIRELESS MULTIMEDIA (WMM) 51 4.2. WMM Y EDCA: CLASIFICACIÓN DE LAS COLAS 52 8 4.3. MAPEADO QOS EN WMM 54 4.3.1. Mapeado QoS desde el nivel de enlace 54 4.3.2. Mapeado QoS desde el nivel de red 55 4.4. MEDIDAS EXPERIMENTALES 59 4.4.1. Primer escenario 59 4.4.1.1. Uso de clientes 802.11 63 4.4.2. Segundo escenario 65 5. CONCLUSIONES 71 6. ANEXO: DISPOSITIVOS HARDWARE 75 6.1. PEPWAVE SURF ON-THE-GO 75 6.2. ESD2: DIGITAL SIGNAGE PLAYER 76 6.3. RASPBERRY PI COMO DIGITAL SIGNAGE PLAYER 78 7. ACRÓNIMOS 83 8. BIBLIOGRAFÍA 87 Índices 9 ÍNDICE DE FIGURAS Figura 1-1: Red DS en distintos puntos geográficos.................................................................................... 15 Figura 2-1: Ejemplo de contenido auto-gestionable. Plantilla basada en flash que confecciona la oferta con una foto, un texto, un precio y una descripción. ................................................................. 19 Figura 2-2: Comunicación del player con el servidor de red ........................................................................ 20 Figura 2-3: Gestión de la red a través del servidor ...................................................................................... 20 Figura 2-4: Etapas en el establecimiento de los túneles del player con el servidor ..................................... 22 Figura 2-6: Comunicación del terminal de control con un player concreto a través del servidor ................. 23 Figura 2-7: Ejemplo de monitorización de los parámetros básicos del player de forma remota .................. 24 Figura 2-8: Ejemplo de gestión del player vía interfaz web de forma remota .............................................. 25 Figura 2-9: Captura de la interfaz web del servidor y de la interfaz de gestión de un player concreto ........ 25 Figura 2-10: Ejemplo de distribución de contenidos de forma remota a través del servidor ........................ 26 Figura 3-1: Diagrama de flujo para la comprobación de los túneles de comunicación ................................ 30 Figura 3-2: Etapas en la actualización de los contenidos ............................................................................ 31 Figura 3-3: Problemática típica en enlaces encadenados tras los que ofrecer QoS E2E ............................ 32 Figura 3-4: Modificaciones propuestas a OpenSSH para gestionar los túneles mediante sockets UDP .................................................................................................................................................... 33 Figura 3-5: Resultado tras emular pérdidas de paquetes ACKs [3] ............................................................. 33 Figura 3-6: Establecimiento tradicional de los tres túneles en sesión única mediante multiplexación. Se plantea cambiar este esquema por sesiones independientes. ...................................................... 35 Figura 3-7: Arquitectura general de Dtrace [5] ............................................................................................. 36 Figura 3-8: Escenario de funcionamiento cliente/servidor echo para medir RTTs a través de túneles SSH .................................................................................................................................................... 37 Figura 3-9: Escenario de pruebas propuesto para el análisis del impacto de tráfico pesado en túneles SSH ........................................................................................................................................ 39 Figura 3-10: RTTs de un túnel SSH sin tráfico extra en otros túneles que comparten sesión ..................... 42 Figura 3-11: Comparativa de RTT’s entre túneles SSH de sesión única y con sesión compartida. ............ 43 Figura 3-12: Comparativa de RTT entre túneles SSH con de sesión única y compartida, ambos con el tamaño de buffer ajustado............................................................................................................... 44 Figura 3-13: Modificación del kernel del player para dar soporte a TCP Vegas .......................................... 46 Figura 3-14: Comparativa de RTTs de túneles SSH con sesión única y con sesión compartida funcionando con TCP Vegas .............................................................................................................. 47 Figura 4-1: Relaciones existentes en el espacio entre trama (IFS)[12] ....................................................... 52 Figura 4-2: Temporizaciones en WMM [13] ................................................................................................. 52 Figura 4-3: Colas de transmisión en un cliente WMM [13] .......................................................................... 53 Figura 4-4: Modificación en la trama Ethernet para incluir el marcaje 802.1Q ............................................ 54 Figura 4-5: Activación de SKB editing en Networking support -> Networking options -> QoS and/or 16 Objetivos 1.2. OBJETIVOS El primer objetivo de este estudio busca minimizar la latencia E2E en la red DS mediante modificaciones y complementos a los algoritmos de comunicaciones y protocolos utilizados que consigan minimizar la congestión y por tanto la latencia; un aspecto muy negativo en la interactividad tanto de los contenidos audiovisuales como en la gestión de los dispositivos. Para ello se estudian todos los elementos principales que intervienen en las comunicaciones entre el player y el servidor y se proponen posibles soluciones. A lo largo de la memoria se proyecta implementar alguna de ellas y constatar la mejora esperada con medidas experimentales. En el ámbito local wireless el objetivo consiste en aprovechar las prestaciones que esta tecnología puede ofrecer para el tráfico diferenciado. Se pretenden priorizar las comunicaciones de control y gestión sobre el resto de tráfico y para ello se analizan las alternativas posibles y se plantean soluciones que se valoran en base a los resultados obtenidos de las medidas experimentales realizadas. 1.3. ESTRUCTURA DE LA MEMORIA Este documento se divide en cuatro capítulos. El primero describe los problemas existentes y los objetivos de trabajo planteados. El segundo capítulo consiste en una breve introducción a la red Digital Signage y a su modo de operación. Se centra en la forma en la que se establecen las conexiones entre los dispositivos para poder disponer de una perspectiva más completa a la hora de abordar los problemas. En el tercer capítulo se analizan los protocolos de comunicación utilizados y la diferenciación del tráfico empleado en estos sistemas. También se estudia la congestión y el efecto del tráfico entre los flujos diferenciados dentro de un mismo túnel. Se describen las herramientas usadas para medir latencias y se proponen soluciones para cada problema planteado. En el cuarto capítulo se aborda el entorno wireless local y se profundiza en la tecnología de calidad de servicio (QoS) de 802.11. Dado que los escenarios en los que se trabaja normalmente no permiten configurar los Access Points (APs) y se desconoce qué tecnologías implementa cada modelo de AP a priori, se centra el análisis en los procedimientos de gestión de acceso al medio definidos por Enhanced Distributed Carrier Access (EDCA) y cómo se pueden utilizar para priorizar el tráfico de control y gestión de los players. Finalmente se analizan dos dispositivos 802.11 y se realizan medidas para comprobar el funcionamiento de EDCA. Finalmente, en la sección 5 se presentan las conclusiones y líneas futuras de trabajo. Estructura básica de una red DS y su funcionamiento Estructura básica de una red DS y su funcionamiento 19 2. ESTRUCTURA BÁSICA DE UNA RED DS Y SU FUNCIONAMIENTO La tecnología Digital Signage no se encuentra estandarizada y cada fabricante de dispositivos propone su propia solución. Este hecho se debe en parte a que falta una definición clara de las funcionalidades que debe disponer una red de este tipo. En Ateire Tecnología y Comunicación, siendo conscientes de este problema, hemos optado por desarrollar nuestra solución basándonos en tecnología web principalmente. Este aspecto dota a nuestro sistema de la flexibilidad necesaria para ser capaz de adaptarse a las necesidades de cada proyecto concreto. Además, al basarse en tecnología abierta facilita la integración de la red DS en otros sistemas de información de terceros. En esta red encontramos dos elementos fundamentales, los players y el servidor central. Los players constituyen el elemento básico de una red de Digital Signage. Pueden ubicarse en cualquier punto donde el propietario de los mismos desee realizar comunicación audiovisual dirigida a trabajadores, potenciales clientes, etc. Estos players muestran por una pantalla contenidos que se pueden tener alojados local ó remotamente. Los contenidos pueden estar basados en fotografía, video ó aplicaciones web más complejas que estén dotadas de cierto grado de interactividad y se conecten a sistemas de información ajenos a la red DS. Un ejemplo de uso generalizado se encuentra en el ámbito publicitario con las plantillas del tipo “oferta de productos” que disponen de conexión a bases de datos de donde obtienen la información de la oferta para generarla on-the-fly. Figura 2-1: Ejemplo de contenido auto-gestionable. Plantilla basada en flash que confecciona la oferta con una foto, un texto, un precio y una descripción. El funcionamiento de estos dispositivos es autónomo una vez quedan programados. Incluso en casos de falta de conectividad, continúan funcionando reproduciendo únicamente contenidos locales. La figura del servidor central se reserva para operaciones de monitorización, control y distribución de contenidos para reproducción en diferido. El gestor de la red DS se conecta a este servidor por interfaz web facilitando así su accesibilidad desde la mayoría de dispositivos con navegadores web. En este portal, el gestor de la red puede listar todos los players que conforman la misma y monitorizar su estado actual (conectado/desconectado, último sondeo realizado, parrilla de contenidos actual, contenido actualmente en reproducción, instantáneas en miniatura actualizadas del mismo, etc.). El gestor de la red también puede controlar cualquier player en concreto. El sistema de gestión de los players se realiza también vía interfaz web y el servidor es capaz de 20 establecer conexión directa a los servidores web de los players para que el gestor de red pueda controlarlos de forma directa si fuese necesario. Antes de exponer las restantes funciones del servidor central conviene definir algunos conceptos: • Canal de contenidos: Consiste en un conjunto de contenidos que tienen ciertas características en común y que se agrupan en un canal para simplificar su distribución. • Grupo de players: Se define como una agregación de estos dispositivos con alguna característica en común: mismo cliente, misma área geográfica, etc. • Parrilla de contenidos: se define como la forma de organizar los contenidos de un grupo o de un único player para su reproducción. Existen varios factores a determinar: los contenidos que van a formar parte de la parrilla, el orden de los mismos y su duración en caso de no tener la asignada intrínsecamente; como ocurre con las fotos, aplicaciones web ó las animaciones cíclicas. En el caso de los vídeos no sería necesario. El servidor central permite la creación de grupos de players, canales de contenidos y la asignación de estos canales a los grupos creados. También gestiona el proceso de sincronización de los canales a los grupos. Las comunicaciones entre los players y el servidor central se realizan mediante túneles SSH (Secure SHell) para dotar a las comunicaciones de seguridad dado que se utiliza Internet como red troncal. Figura 2-2: Comunicación del player con el servidor de red En base a los servicios definidos y la forma de conexión elegida se pueden exponer algunas consideraciones generales sobre las características de las comunicaciones entre servidor central, player y gestor de red: • Los contenidos que obtiene el player pueden proceder del servidor o de otro punto de Internet: Una página web, video en streaming, rss feeds, etc. Los contenidos del servidor siempre son en diferido y se precargan en el player, mientras que los que se pueden obtener por Internet pueden ser en tiempo real. • Por otro lado, el gestor de red puede acceder a los servicios que ofrece la red DS a través del servidor central. Este supone un punto neurálgico de la red donde se concentra la información y el estado de todos los players de la red. El servidor ofrece servicios de gestión de los contenidos y la programación de los players. Figura 2-3: Gestión de la red a través del servidor Túnel SSH Estructura básica de una red DS y su funcionamiento 21 • A su vez, el servidor puede compartir túneles SHH con el gestor de red si éste requiere comunicación directa con el player. Las comunicaciones del gestor de red con el servidor son vía web en usando HTTP/HTTPS. Las comunicaciones de gestión sobre un player concreto de la red circulan del terminal del gestor de red al player a través del servidor central por medio de un túnel ssh que el servidor tiene reservado con ese cometido para cada player. Tras esta breve explicación, se pueden identificar 4 tipos de tráfico que cursará esta red: • Tráfico de control: Generado por las tareas de control y monitorización entre el player y el servidor. • Trafico de gestión: Generado por las tareas que el administrador de la red realiza en el servidor mediante su terminal de gestión. • Tráfico de contenidos: Puede ser de dos tipos: o En tiempo real: Contenidos solicitados por player que se reproducirán en el momento de su solicitud. o En diferido: Contenidos que se descargan en el player y que se reproducirán posteriormente según la programación efectuada. 2.1. COMUNICACIÓN ENTRE EL SERVIDOR Y LOS PLAYERS 2.1.1. Conectividad con Internet La red DS expuesta en el apartado anterior está diseñada para ser escalable y flexible. Los players deben ser capaces de registrarse en la red DS de la manera más transparente posible para simplificar las tareas del gestor de red y del despliegue de los players. Para ello la red DS, cuando debe registrar un nuevo player, opera según el siguiente procedimiento: El player toma la iniciativa de buscar acceso a Internet. Existen modelos de players con interfaz de red Ethernet 802.3 y otros modelos con interfaz Wi-Fi 802.11 y 3G. En este último caso, el dispositivo puede contar con diversas Service Set IDentifier (SSID) de 802.11 en memoria y busca aquella que esté disponible y cuyo AP sea detectado con mayor potencia. En caso de que la conexión Wi-Fi no sea posible y no exista ninguna red memorizada disponible, procede a utilizar la red 3G preconfigurada como conexión de backup ó de fail-over. En caso de que al cabo de un tiempo predeterminado se detecte alguna de las redes Wi-Fi configuradas y la conexión a la misma se establece con éxito, el dispositivo modifica el enrutamiento de las comunicaciones hacia Internet por la interfaz Wi-Fi desconectando la conexión de datos de la interfaz 3G. Este comportamiento es común en las tareas de configuración remota de los dispositivos recién adquiridos por un cliente. Los players con capacidades Wi-Fi/3G se envían al lugar de instalación y se configuran remotamente a través de 3G. No obstante este sistema también se emplea en dispositivos móviles como vehículos: la conectividad 3G es vital cuando el vehículo se encuentra en movimiento y la conectividad Wi-Fi se emplea cuando el vehículo se encuentra estacionado para actualizar contenidos pesados. 22 Comunicación entre el servidor y los players 2.1.2. Establecimiento de las conexiones tuneladas Una vez que el player dispone de acceso a Internet, éste intenta registrarse en la red DS que tiene como punto neurálgico el servidor central. Cuando un player se registra en la red DS establece una primera conexión SSH con dicho servidor central. Para ello, los players vienen configurados de fábrica para que dispongan de un par de llaves público/privada únicas. De ese modo pueden realizar una conexión al servidor central con la que sólo tienen derecho a solicitar una terna de valores que corresponden con los puertos reservados en el servidor para las comunicaciones del tráfico con ese player determinado en ese momento concreto. El servidor, en esa comunicación, elige y reserva una terna de puertos de forma aleatoria entre 1024 y 65535 que estén disponibles: sin usar y sin reservar. Una vez que el player dispone de estos puertos finaliza la conexión establecida y realiza una nueva en la que configura túneles reversos desde el servidor central hacia sí mismo tal y como se aprecia en la siguiente figura: Figura 2-4: Etapas en el establecimiento de los túneles del player con el servidor Reserva de terna del puertos para el player en servidor central Conexión SSH vía par de llaves público/privada Nueva conexión SSH y establecimiento de túneles reversos Estructura básica de una red DS y su funcionamiento 23 Tabla 3-1: Descripción de los túneles empleados en cada player Los puertos origen en el servidor se han denominado x, y, z, por ser valores enteros variables entre 1024 y 65535. Los túneles formados se emplean para transmitir la información relativa a la administración del player vía interfaz web, la monitorización del mismo por parte del servidor y la transmisión de contenidos diferidos. La asignación de estos puertos se guarda en una base de datos del servidor a la que tienen acceso las aplicaciones web de gestión de la red, los scripts del servidor relativos a la monitorización periódica de los players y las solicitudes de sincronización de contenidos por parte de las aplicaciones web de gestión. 2.1.3. Servidor de Digital Signage: Gestión de conexiones En las redes DS pueden existir numerosos gestores de red con acceso a la monitorización de los parámetros de los players. Es común el utilizar consolas de monitorización de forma constante en pantallas para visualizar el estado de la red. Esta cantidad de información puede suponer un uso no despreciable del ancho de banda disponible para cada player y por tanto se ha optimizado su distribución a través del servidor. Figura 2-5: Comunicación del terminal de control con un player concreto a través del servidor Número de túnel Puerto destino en player Puerto origen en Servidor Función 1 22 x Tráfico de control y monitorización 2 80 y Tráfico web de gestión 3 2222 z Tráfico de contenidos Id player Puertos reversos Información de sondeo 1 (22,𝑥1) (80,𝑦1) (2222, 𝑧1) …… 2 (22,𝑥2) (80,𝑦2) (2222, 𝑧2) …… 24 Comunicación entre el servidor y los players 2.1.3.1. Monitorización de los players Cada vez que un gestor de red se autentifica correctamente en el portal de gestión del servidor, éste marca con unos flags las entradas de los players correspondientes a monitorizar en la base de datos. De este modo, el servidor comienza a realizar sondeos periódicos a los players marcados y a registrar esa información en la base de datos de los players. La información de sondeo que se visualiza en el terminal de control es la guardada en la base de datos por el servidor, consiguiendo que, independientemente del número de terminales de control existentes, sólo se acceda una vez a cada player periódicamente. Figura 2-6: Ejemplo de monitorización de los parámetros básicos del player de forma remota 2.1.3.2. Gestión de los players El acceso remoto para la gestión individual de cada player a través del servidor se realiza mediante la aplicación web de gestión local de que dispone1. Esta aplicación autentifica automáticamente al gestor de red en cualquier dispositivo que esté bajo su control pudiendo acceder a la página de gestión del aparato a través del túnel correspondiente. El servidor busca en la base de datos el túnel asignado para gestión del player concreto y redirige la solicitud web de gestión a través de ese túnel mostrando la web de gestión en un iframe de la web del servidor. En caso de que el gestor de red no estuviese autentificado en el servidor e intentase acceder directamente al puerto correspondiente al túnel de gestión del player, la web de gestión del player no permitiría e1l acceso, pues el servidor no lo ha autentificado. 1 Los players pueden tener un funcionamiento autónomo del resto de players y del servidor. Disponen de una página de gestión vía interfaz web que se puede localizar a través de protocolos Universal Plug and Play (UPnP) y Simple Service Discovery Protocol (SSDP) en la red local en la que está ubicado. Estructura básica de una red DS y su funcionamiento 25 Figura 2-7: Ejemplo de gestión del player vía interfaz web de forma remota A día de hoy se está trabajando en reforzar la seguridad programando en el propio servidor un firewall inteligente que permita el acceso a los puertos de un player en concreto según restricción de IPs y de gestores de red autentificados en la web de gestión del servidor, ofreciendo mayor seguridad. Sin este sistema, cualquier dispositivo puede acceder a la web de autentificación y servidor SSH de cualquier player por los puertos reversos. La web de gestión del servidor se divide en dos áreas: La sección superior presenta el listado de los players a los que el gestor de red tiene acceso. Muestra información actualizada cada 7s (de izquierda a derecha) Id del player, alias, captura del contenido actualmente en pantalla, estatus del player, momento del último sondeo, lista de contenidos activa, contenido activo (número y url). Figura 2-8: Captura de la interfaz web del servidor y de la interfaz de gestión de un player concreto 32 Aspectos mejorables en la red 3.1.3. Diferenciación del tráfico Existen diversos problemas para mejorar el grado de QoS E2E en el escenario propuesto playerservidor. La conexión del player con Internet se suele realizar a través de una red local en la que se encadenan distintos enlaces: Figura 3-3: Problemática típica en enlaces encadenados tras los que ofrecer QoS E2E “Narrow link” representa el enlace que fijará el límite máximo de ancho de banda disponible, mientras que “Tight link”, fijará la máxima tasa binaria posible. En un escenario real, “Narrow link” puede estar representado por el enlace ADSL, mientras que “Tight link” puede representar el enlace WI-FI. Teniendo esta estructura en cuenta, podemos deducir que el ancho de banda máximo disponible para el enlace vendrá limitado por el ADSL. Podría ocurrir que el ancho de banda del servidor central con Internet fuera insuficiente, en cuyo caso, la suposición anterior no sería válida. Sin embargo, al ser un servidor dedicado y disponer de un Service Level Agreement (SLA) con la empresa concesionaria del mismo, se puede asegurar la disponibilidad de ancho de banda en ese extremo y tener monitorizado su consumo. Para poder ofrecer QoS E2E en este ámbito debería existir, por tanto, algún tipo de ingeniería de tráfico en el router ADSL que realizase reserva de ancho de banda o traffic shapping sobre el tráfico cursado por el “Narrow Link”, y esta posibilidad no resulta viable en general ya que sólo se dispone de acceso al player de Digital Signage. Sin embargo, sí es factible en redes planificadas de Digital Signage a desplegar en las que se pueda efectuar una planificación previa. Por otro lado, se ha planteado la posibilidad de gestionar el tráfico cursado por el player desde el propio player con técnicas de planificación de tráfico. Sin embargo, para que funcionasen de forma efectiva, habría que calcular periódicamente el ancho de banda disponible E2E, pues en todas ellas se usa como parámetro. Obtener ese dato es complicado dado que el “Narrow link” no conecta directamente con el player, existiendo elementos intermedios de red con buffers de entrada de paquetes que dificultan la tarea de medir el ancho de banda extremo a extremo con un mínimo overhead [1]. Por consiguiente, en este escenario, resulta muy difícil de medir el ancho de banda E2E con cierta precisión, rapidez y manteniendo la fiabilidad frente a cambios en la red quedando esta alternativa descartada. Player Router/AP QoS en la gestión de la red 33 3.1.4. Optimización del protocolo SSH en comunicaciones tuneladas El sistema de conexión de los players con el servidor que se ha planteado usa un sistema de túneles que utiliza TCP sobre TCP. Esta forma de tunelado tiene un comportamiento aceptable únicamente mientras exista suficiente ancho de banda en exceso en el conjunto de redes por las que circula el túnel. De no ser así, los temporizadores TCP pueden explicar y el rendimiento disminuye notablemente debido a las retransmisiones produciéndose lo que se conoce como “tcp meltdown problem” [2]. Para solucionar este problema, se propone la implementación de una versión modificada ya existente de OpenSSH en la que la tunelación se realizará mediante el protocolo UDP [3]. Figura 3-4: Modificaciones propuestas a OpenSSH para gestionar los túneles mediante sockets UDP De este modo, una estructura de túneles TCP sobre UDP evita las ineficiencias derivadas de las pérdidas de Acknoledgements (ACKs) al usar TCP sobre TCP Figura 3-5: Resultado tras emular pérdidas de paquetes ACKs [3] 34 Aspectos mejorables en la red La implementación de esta versión modificada de OpenSSH no se aplicará inmediatamente, ya que pese a estar desarrollada en la actualidad, es necesario someterla a una batería de pruebas que certifiquen su correcto funcionamiento en los escenarios más comunes para intentar no comprometer el funcionamiento de la red DS. Por ello se propone además no prescindir de la implementación actual de OpenSSH y añadir esta nueva versión permitiendo utilizar una u otra según convenga. 3.2. MEJORA DE LA LATENCIA MEDIANTE EL CONTROL DE CONGESTIÓN Todos los aspectos expuestos en el apartado anterior tratan por separado de minimizar la congestión en la red de diversas maneras, pero ninguna resulta suficiente. Para solucionar los problemas derivados de la congestión se debe gestionar la congestión de forma más global desde los protocolos de comunicación. Para regular el tráfico generado por el player y evitar que los flujos de datos de menor relevancia dificulten las operaciones de control y/o gestión, se profundiza en la forma que SSH gestiona la transmisión de información. Para ello, hay que tener en cuenta que SSH versión 2 multiplexa los canales de cada conexión de la sesión [4] evitando enviar más datos relativos a un canal concreto hasta que no se indica explícitamente un mensaje de ventana disponible para ese canal. Con esta medida, se evita, por ejemplo, que una transmisión SFTP se adueñe del ancho de banda disponible en uno de los sentidos de las comunicaciones y permite a las aplicaciones de gestión y control competir por el acceso al ancho de banda. Figura 3-6: Establecimiento tradicional de los tres túneles en sesión única mediante multiplexación. Se plantea cambiar este esquema por sesiones independientes. Esta forma de gestionar las comunicaciones en las sesiones SSH, beneficia al conjunto de las restantes transmisiones del dispositivo pero pueden afectar al resto de conexiones multiplexadas en esa misma sesión SSH. Por ello, parece recomendable establecer cada túnel en una sesión SSH independiente. De este modo, al utilizar tres sesiones SSH diferentes, se aplica el control de congestión de cada una de ellas reduciendo el efecto del tráfico pesado sobre el tráfico de control y gestión. Para validar la efectividad de esta medida se propone medir el Round-Trip delay Time (RTT) de los túneles en ambos escenarios: Compartiendo sesión y estando multiplexado con una transmisión SFTP y encontrándose en sesiones SSH independientes. El RTT supone un indicador del grado de latencia experimentada en las aplicaciones web de control y gestión de la red DS. 3.2.1. Herramientas para medir el Round-Trip delay Time (RTT) El RTT representa el tiempo que tarda un paquete de datos en viajar desde el emisor hasta el receptor y volver su ACK al emisor. Esta medida sirve para analizar determinados aspectos de la red permitiendo extraer conclusiones relativas al rendimiento de la red y su funcionamiento si se tiene en cuenta correctamente las condiciones en las que se realizan estas medidas. 36 WMM y EDCA: Clasificación de las colas Existen numerosas herramientas disponibles, pero sólo deben emplearse aquellas que resulten adecuadas para evaluar el RTT de una conexión tunelada. A continuación se exponen algunas de las herramientas analizadas. 3.2.1.1. Dtrace Esta herramienta se define como un pseudo lenguaje de programación que se utiliza para monitorizar el estado del funcionamiento de los procesos internos del sistema operativo, permitiendo realizar modificaciones en ellos y facilitar la búsqueda de problemas. Dtrace hereda la sintaxis de C, complementándola con funciones y variables específicas para facilitar la depuración. Dtrace dispone de un módulo que se carga con el kernel y con el que se comunica un comando que puede ejecutar scripts dtrace. Esta herramienta permite modificar dinámicamente los procesos del kernel del sistema para obtener información adicional de interés llamadas probes. Una probe consiste en una dirección de memoria o actividad del sistema a la que dtrace puede incorporarse para efectuar una serie de acciones, como obtener un volcado de stack, una marca de tiempo o un argumento de función. Las probes pueden entenderse como sensores que disparan sucesos que se encargan de recopilar la información de interés. Estas funciones se programan en los scripts y se relacionan a una probe específica para dispararlos. Los scripts son compilados en el momento de su ejecución y cargados cuando se dispara alguna de las probes Figura 3-7: Arquitectura general de Dtrace [5] Esta herramienta podría utilizarse para realizar mediciones de parámetros relacionados con el funcionamiento de TCP e IP en las comunicaciones entre el player y el servidor. Sin embargo, la versión de dtrace para Linux todavía sólo ofrece funcionalidad limitada. La herramienta es originaria de Solaris y para conseguir hacerla funcionar en Linux se deben seguir instrucciones específicas para generar su módulo del kernel [5][6] QoS en la gestión de la red 37 Tras reiterados intentos no pudo instalarse en el player, ya que dtrace parece ser muy dependiente de la versión de kernel empleada. Una posible alternativa consistiría en instalar una máquina virtual Solaris y usar su dtrace, pero realizar eso en el player es complejo y por consiguiente esta herramienta se descarta para este propósito. 3.2.1.2. Hping3 Otra herramienta utilizada para medir el RTT es Hping3[7], pero tampoco resulta útil para este caso en concreto en el que se tiene que medir la latencia E2E de un túnel. La aplicación dispone de opciones para hacer ping a puertos utilizando los flags de TCP como el Sync para forzar una respuesta. Esta filosofía funciona para medir el RTT cuando se realiza de máquina a máquina, pero al invocar el comando contra el puerto de un túnel SSH, Hping se comunica con el socket que SSH prepara localmente para ese túnel de ese mismo extremo y por tanto no se mide el RTT, puesto que eso debería efectuarse en el socket del otro extremo del túnel y no es posible. 3.2.1.3. Tcpdump y tcptrace Combinando tcpdump y tcptrace[8] se pueden utilizar para efectuar volcados de tráfico y analizar las trazas para interpretar los paquetes enviados y recibidos y obtener datos estadísticos de las latencias. Sin embargo, dado que las comunicaciones por el túnel se encuentran encriptadas, no resulta inmediata la medición del tráfico cursado por los túneles, teniendo que recurrir a interfaces loop-back puente que también deben monitorizarse. Wireshark puede obtener datos similares pero experimenta el mismo problema. 3.2.1.4. Medida directa del RTT sobre mensajes echo tunelados Para realizar una medición RTT sobre los túneles se propone realizar las medidas de RTT sobre mensajes mandados a través del túnel al puerto echo del servidor destino. Figura 3-8: Escenario de funcionamiento cliente/servidor echo para medir RTTs a través de túneles SSH Cliente Echo TCP/IP SSH TCP/IP Servidor Echo TCP/IP SSH TCP/IP 38 WMM y EDCA: Clasificación de las colas Esta medida registra el RTT percibido por el sistema de gestión o el administrador de forma más realista, pues se lleva a cabo a nivel de aplicación. Para ello se emplea un cliente echo que se pueda tunelar por TCP: #!/usr/bin/env python import socket host = '127.0.0.1' port = 7777 size = 1024 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((host,port)) s.send('Hola, mundo') data = s.recv(size) s.close() print 'Recibido:', data Las medidas de RTT se pueden obtener a partir del comando time ejecutado sobre el cliente echo generando un archivo de resultados tal y como se efectúa en el apartado 3.2.2.3 de esta memoria. 3.2.2. Impacto en la latencia del tráfico debido a los túneles que comparten sesión por multiplexación. El objetivo de estas medidas es el de cuantificar el efecto en la latencia del tráfico de gestión y control que tiene en esta red el establecimiento de túneles multiplexados en una misma sesión en la que existe un túnel con tráfico pesado de datos. Todas las comunicaciones entre cada player y el servidor central se establecen en túneles que comparten una única sesión por player. Sin embargo, según lo expuesto en el apartado 3.2, puede mejorarse la latencia usando túneles con sesiones independientes debido a que el control de congestión que aplica SSH se efectúa por sesiones y no por túneles. Para validar este hecho se realizan algunas medidas que contrastan datos de latencia de túneles SSH cuya sesión se comparte con una transferencia masiva SFTP frente a otro túnel que, simultáneamente se monitoriza y cuya sesión SSH es independiente de la anterior. 3.2.2.1. Metodología El procedimiento a seguir para poder cuantificar la latencia extra experimentada por un túnel SSH multiplexado con otro con trafico SFTP pesado frente a un túnel sin multiplexar en sesión SSH independiente consiste en evaluar el RTT del túnel independiente frente al RTT del túnel multiplexado con la transferencia SFTP. Los túneles se establecen desde un player de la red hasta el servidor DS en Montreal tal y como se expone en la siguiente tabla: QoS en la gestión de la red 39 Tabla 3-1: Configuración de los túneles empleados en las pruebas experimentales La única diferencia entre los dos clientes echo es el puerto al que lanzan sus peticiones de eco. Figura 3-9: Escenario de pruebas propuesto para el análisis del impacto de tráfico pesado en túneles SSH Se establecen tres comunicaciones tuneladas. Por dos de ellas se establece una comunicación SSH con el servidor y por la tercera un túnel SFTP. El túnel con comunicación SFTP comparte sesión SSH con una de las otras comunicaciones para poder estudiar el impacto del tráfico SFTP masivo en el túnel que comparte sesión frente al túnel de sesión independiente. Una vez establecidos los túneles se ejecutarán de forma sincronizada sondeos echo a través del túnel independiente y del túnel multiplexado en varios escenarios: En primer lugar, se aplicarán estos sondeos en el túnel SSH independiente sin enviar datos por la conexión SFTP. De este modo se obtienen los valores de RTT de referencia en el mejor escenario posible: Sólo una comunicación SSH y la comunicación SFTP inactiva. Posteriormente, se procede a realizar medidas de RTT con la comunicación SFTP a plena carga. Para ello se efectúan sondeos simultáneamente en ambos túneles SSH y se representan los valores RTT obtenidos en un gráfico dónde se podrán comparar las diferencias de latencia. Puerto origen en player Puerto destino en Servidor Función Comando ejecutado para sondear 7777 7 Medición de RTT a través de un túnel independiente Cliente echo: echo_tunel_simple.py 7778 7 Medición de RTT a través de un túnel multiplexado con otro con tráfico pesado Cliente echo: echo_tunel_multiple.py 2222 22 Túnel con tráfico pesado SFTP 40 WMM y EDCA: Clasificación de las colas Finalmente se modifican ciertos parámetros de las comunicaciones para controlar la congestión y reducir la latencia. Se realizan sondeos en este escenario y se valoran los resultados obtenidos para exponer unas conclusiones. 3.2.2.2. Creación de los túneles Para establecer los túneles se ejecutan los siguientes comandos: ssh -L7777:127.0.0.1:7 ateire.com ssh -L2222:127.0.0.1:22 -L7778:127.0.0.1:7 ateire.com En la primera línea se crea un túnel simple, con puerto local en el player 7777 que conduce al puerto remoto echo (7) del servidor central. En la segunda se establece una sesión con dos túneles, el que tiene puerto local 2222 se usará para transmitir vía SFTP datos constantemente al servidor central e intentar ocupar todo el ancho de banda E2E disponible. El puerto 7778 local también se comunica con el puerto echo del servidor central. 3.2.2.3. Ejecución de los clientes echo para obtener RTTs Las pruebas siguientes se realizan para comprobar si se perjudica la latencia del tráfico en un túnel que comparte sesión SSH OpenSSH v2 con otro que requiere un uso intensivo del ancho de banda. Para ello se habilita sobre el túnel de datos (2222) una sesión SFTP a través de la cual se transmite una ráfaga de datos constantemente a la velocidad que permite el escenario propuesto. sftp -oPort=2222 127.0.0.1 Posteriormente se ejecutan dos clientes echo: Uno contra el puerto local 7777 (echo_tunel_simple.py) y otro contra el puerto local 7778 (echo_tunel_multiple.py) mediante un script sh que se encarga de ejecutarlos de forma sincronizada recursivamente y apuntando en un log los tiempos necesitados por cada cliente echo para ejecutarse. De este modo, el script sh genera las llamadas a los scripts python síncronamente y obteniendo medidas de tiempo que pueden compararse para poder deducir el tiempo extra del RTT según el túnel empleado. QoS en la gestión de la red 41 sondeos_echo.sh #!/bin/sh ahora=`date +%s%N | cut -b1-13` echo "" >echo_tunel_simple.log echo "" >echo_tunel_multiple.log function sondeo() { tipo=$1 momento=`date +%s%N | cut -b1-13` salida=`(time $tipo".py") 2>&1` rtt=`echo $salida | grep real | cut -f 2 -d 'm' | cut -f 1 -d 's'` transcurrido=$(($momento-$ahora)) t=`awk 'BEGIN{printf("%0.3f", '$transcurrido' / '1000' )}'` echo $t $rtt >>$tipo".log" } for ((i = 0; i < 250; i++)) do sondeo echo_tunel_simple& pid_sondeo_tunel_simple=$! sondeo echo_tunel_multiple& pid_sondeo_tunel_multiple=$! wait $pid_sondeo_tunel_simple wait $pid_sondeo_tunel_multiple done Este script genera dos logs: “echo_tunel_simple.log” y “echo_tunel_multiple.log” con dos columnas de cifras. La primera indica el tiempo en milisegundos transcurrido desde que comienza la prueba y la segunda indica el RTT en milisegundos de cada petición. Los datos obtenidos son representados con Gnuplot. La ubicación geográfica del cliente y del servidor en estas pruebas es importante. El servidor está en Montreal, Canadá y el cliente en Zaragoza. Además debe tenerse en cuenta que los valores RTT obtenidos no representan exclusivamente la latencia del túnel, ya que la ejecución de los scripts también contribuye: Tabla 3-2: Valores de referencia de latencias obtenidos como promedio de 16 medidas espaciadas a lo largo de las pruebas experimentales. RTT Ping desde Zaragoza hasta Montreal 125 ms en promedio Ejecución del cliente y su medición del tiempo empleado en una conexión no tunelada 260 ms en promedio Ejecución del cliente conectándose a servidor echo en local 105 ms en promedio QoS con enlaces 802.11 QoS con enlaces 802.11 51 4. QOS CON ENLACES 802.11 La influencia del tipo de acceso a Internet que dispone el player es muy elevada dependiendo de la tecnología empleada. Concretamente, en entornos wireless 802.11 existen algunas herramientas que permiten gestionar el tráfico en escenarios con congestión en la red local para mejorar la QoS percibida. Para ello, la problemática a tratar en este apartado consiste en cómo abordar la planificación y marcaje del tráfico de salida del dispositivo para intentar favorecer el correcto funcionamiento del player independientemente del estado de congestión de la red local. Sólo se contempla trabajar en el tráfico upload, puesto que por norma general se desconoce el tipo de punto de acceso 802.11 presente (b/g/n, fabricante, si es compatible con Wireless MultiMedia (WMM), etc). . 4.1. DESCRIPCIÓN DE WIRELESS MULTIMEDIA (WMM) La tecnología WMM representa una mejora de la subcapa MAC para añadir prestaciones de calidad de servicio a las redes Wi-Fi. WMM recoge partes del estándar 802.11e y supone una extensión del sistema de coordinación distribuida (DCF) para acceder al medio inalámbrico. Este sistema intenta ofrecer a todos los dispositivos la misma prioridad y oportunidad de acceder al medio basándose en el algoritmo “listen-before-talk”. En este escenario, cada cliente espera un tiempo aleatorio de backoff y entonces se transmite sólo si no hay otro dispositivo transmitiendo en ese momento. Esta forma de evitar colisiones da a los dispositivos la oportunidad de transmitir pero bajo determinadas circunstancias de alta carga de tráfico se ve afectado el rendimiento de este sistema y su ecuanimidad con los diversos clientes Wi-Fi. Tabla 4-1: Listado de las categorías de acceso en WMM y su correspondencia con las prioridades 802.1d de Ethernet [11] Categoría de acceso (AC) Descripción 802.1d tags Prioridad de voz WMM La prioridad más alta. Permite múltiples llamadas de voz sobre IP (VoIP) con baja latencia. 7,6 Prioridad de video WMM Prioriza el tráfico de vídeo sobre otros datos de tráfico. 5,4 Prioridad “Best Effort” WMM Tráfico de dispositivos que carecen de prestaciones QoS ó tráfico menos sensible a latencia pero al que le afectan retardos elevados como la navegación por Internet. 0,3 Prioridad Background WMM Tráfico de baja prioridad como descargas de ficheros y traba jos de impresión que no tienen requisitos estrictos de latencia y ancho de banda. 2,1 52 WMM y EDCA: Clasificación de las colas 4.2. WMM Y EDCA: CLASIFICACIÓN DE LAS COLAS WMM introduce capacidad de priorización de tráfico basado en las cuatro clases de tráfico ya listadas en la Tabla 4-1. Las categorías de acceso reciben más prioridad para transmitir cuanto mayor sea su nivel de clasificación. Esta forma de abordar la gestión del tráfico solventa la falta de diferenciación de los flujos y hace posible la priorización del acceso al medio de unos frente a otros. Además, la planificación del sistema WMM permite la coexistencia de dispositivos compatibles con WMM con aquellos que no lo son. Esta planificación llamada denominada EDCA se puede efectuar de modo distribuido sin intervención del AP y se incorpora del estándar 802.1e Figura 4-1: Relaciones existentes en el espacio entre trama (IFS)[12] La priorización de WMM funciona tal y como se muestra en la Figura 4-2 y en la Figura 4-3. Las aplicaciones asignan cada paquete de datos a una clase de acceso concreto (AC). Los paquetes, se añaden posteriormente a cada una de las cuatro colas de transmisión independientes en el cliente (una por cada AC: voz, video, best effort y background). Figura 4-2: Temporizaciones en WMM [13] El cliente dispone de un sistema para resolver colisiones internas en las contiendas por acceder al medio que se resolverán de forma similar a como se actúa posteriormente entre estaciones. Para ello se QoS con enlaces 802.11 53 establece un algoritmo distribuido que determina qué cliente dispondrá de la oportunidad para transmitir (TXOP) Figura 4-3: Colas de transmisión en un cliente WMM [13] El algoritmo de resolución de colisiones responsable de la priorización de tráfico es de carácter probabilístico y depende de dos parámetros que varían para cada clase de acceso (AC): • El tiempo mínimo entre tramas o el Arbitrary Inter-Frame Space Number (AIFSN). • El tamaño de la ventana de contención, a veces referido como tiempo aleatorio de backoff. Estos dos valores son pequeños para tráficos de alta prioridad y mayores según disminuya la prioridad. Para cada AC, se calcula un tiempo de backoff como la suma del AIFSN y un valor aleatorio comprendido entre el 0 y el valor de la ventana de contención (CW) que varía a lo largo del tiempo. Inicialmente el CW se inicializa a un valor que depende del AC, pero tras cada colisión, el CW se dobla hasta que se alcanza el valor máximo (también dependiente del AC). Tras una transmisión exitosa el valor del CW se reinicia a su estado inicial dependiente del AC. El AC con el backoff menor obtiene el TXOP. Las tramas con AC superiores disminuyen progresivamente su backoff para incrementar la probabilidad de acceder al medio (un TXOP) Tabla 4-2: Parámetros por defecto de EDCA para 802.11 y WMM [11] WMM recoge en sus especificaciones el sistema EDCA y opcionalmente otras prestaciones de 802.11e como WMM Scheduled Access (WMM-SA), Direct Link Setup (DLS) block acknowledgment (B- ACK), y técnicas de ahorro energético. Resulta conveniente, por tanto, averiguar el grado de 54 WMM y EDCA: Clasificación de las colas aprovechamiento de WMM por un cliente compatible con esta tecnología que accede a una red 802.11 que no da soporte. En ese escenario se empleará EDCA. 4.3. MAPEADO QOS EN WMM Para poder emplear EDCA en el player, se ha de indicar al dispositivo 802.11 cuál es la prioridad de la información que en cada momento debe transmitir. Para ello, se puede realizar un marcado en el nivel de enlace, el nivel de funcionamiento de WMM, o en el nivel de red, pues el estándar especifica que WMM también ha de ser capaz de interpretar niveles de prioridad IP del campo TOS [13] 4.3.1. Mapeado QoS desde el nivel de enlace Para conseguir que el tráfico que generamos en los players se clasifique en un tipo de AC o en otro, se puede marcar a nivel 2 el tráfico para que, posteriormente y según 802.1p, el driver Wi-Fi del player pueda clasificarlo en el AC correspondiente. Este marcaje va en una etiqueta opcional de Ethernet, la 802.1Q, y al incluirla, se recalcula el código de redundancia cíclica de trama (CRC). Preámbulo Inicio de trama MAC destino MAC origen Tipo/Long. Datos CRC Gap entre tramas 7 Bytes 1 Byte 6 Byte 6 Byte 2 Byte Hasta 1500 Bytes 4 Bytes 12 Bytes Preámbulo Inicio de trama MAC destino MAC origen Tipo/Long. Etiqueta 802.1Q Datos CRC Gap entre tramas 7 Bytes 1 Byte 6 Byte 6 Byte 2 Byte 4 Bytes Hasta 1500 Bytes 4 Bytes 12 Bytes Figura 4-4: Modificación en la trama Ethernet para incluir el marcaje 802.1Q Sin embargo, en Linux, la posibilidad de marcar directamente tráfico a nivel 2 está muy restringida. La forma más directa de hacerlo es utilizando VLANs y valiéndonos de 802.1Q. Para ello, se crearían interfaces virtuales por las que se redirigir el tráfico que considerásemos oportuno. Este tráfico quedará marcado con las tags 802.1Q. Marcar directamente 802.1p teóricamente es posible con un nuevo filtro de iptables [21] según el cual se pueden poner etiquetas 802.1p si el driver lo permite. En primer lugar indicamos a Eth0 como interfaz con VLANs configuradas de prioridad 2 y 3 vconfig set_egress_map eth0 3 3 vconfig set_egress_map eth0 2 2 QoS con enlaces 802.11 55 Luego usamos la capacidad de editar los buffers de socket del kernel de Linux: Figura 4-5: Activación de SKB editing en Networking support -> Networking options -> QoS and/or fair queuing # ej de filtrado por ToS [22] y marcado a nivel skb (Linux Socket Buffers) [23]: tc qdisc add dev eth0 root handle 1: sfq tc filter add dev eth0 parent 1: protocol ip u32 match ip tos 0x48 0xff action skbedit priority 2 tc filter add dev eth0 parent 1: protocol ip u32 match ip tos 0x68 0xff action skbedit priority 3 tc filter add dev eth0 parent 1: protocol ip u32 match ip tos 0x00 0xff action skbedit priority 0 Para validar el marcado, habría que capturar ese tráfico realizando las conexiones a un hub en el que conectemos el terminal en modo promiscuo, ya que un router convencional que no implemente VLANs suprime dichas tags. Por otro lado, la validación del marcaje a nivel 802.1p o q en la máquina origen o destinataria tampoco es posible. Según [24] No se tienen garantías de poder capturar el tráfico 802.1q en el terminal que manda el tráfico ya que el driver de la tarjeta puede quitar la etiqueta antes de que podamos obtenerla con wireshark o tcpdump. La alternativa podría ser trabajar en un switch que permita monitorización de tráfico de puertos. Para ello, se puede utilizar el software DD-WRT corriendo en alguno de los dispositivos compatibles [25] y duplicar y redirigir el tráfico objeto del análisis al terminal con wireshark [26]. Sin embargo, dado que no se dispone en este momento del material necesario para proceder con las medidas empíricas, se procede a realizar las pruebas de marcaje a nivel 3. 4.3.2. Mapeado QoS desde el nivel de red Para poder clasificar los tráficos en los 4 ACs de WMM tenemos otra alternativa. Aunque el nivel dos de capa OSI no debería poder examinar los niveles superiores para averiguar su calidad de servicio, es una práctica que se emplea de facto y por consiguiente marcando adecuadamente el campo TOS de IP se puede conseguir clasificación de QoS a nivel inferior. 56 Mapeado QoS en WMM Una vez mapeado la QoS a nivel 2, WMM lo interpreta clasificando el tráfico en colas según la Tabla 4-4. En IPv4 el campo de Type of Service (ToS) se emplea para definir el campo Differenciated Services Code Point (DSCP) [14] y el Explicit Congestion Notification (ECN) [15] Figura 4-6: Ubicación del campo ToS en IPV4 y sus partes principales. Tabla 4-3: Nomenclatura de los bits del campo ToS en IPv4[16] S5 (P2) S4 (P1) S3 (P0) S2 S1 S0 CN CN Los campos P2, P1, P0 se dedican para definir el nivel de prioridad del tráfico. Los bits S2, S1 y S0 caracterizan el tráfico con requisitos de retraso (s2) y ancho de banda (s1). S0 no se usa y siempre está a cero. A su vez, CN1 y CN0 que se plantearon como señalización de congestión [15] han quedado obsoletos y tampoco se emplean. Por norma general van a 0. En base a los bits de prioridad, se pueden definir los siguientes niveles: QoS con enlaces 802.11 57 Tabla 4-4: Correspondencia de los niveles de prioridad DSCP con los tags 802.1D y los AC de 802.1e y WMM[13] P2 P1 P0 802.1D AC 0 0 0 0 BE 0 0 1 1 BK 0 1 0 2 BK 0 1 1 3 BE 1 0 0 4 VI 1 0 1 5 VI 1 1 0 6 VO 1 1 1 7 VO En la Tabla 4-4, se muestra la relación entre los distintos niveles de prioridad a nivel 3, 2 y 802.11 cuando se emplea 802.11e/WMM Respecto los bits S, se define el comportamiento de los paquetes por salto ó Per Hop Behavior (PHB).  Default PHB: DSCP: ”00000000”. Este es el ToS que recibe el tráfico por defecto, recibiendo un comportamiento de Best Effort.  Expedited Forwarding (EF) PHB[17]: Este tipo de marcaje se reserva para tráfico con altos requisitos de prioridad, y condiciones de ancho de banda y retardo estrictas. Este tipo de información sirve a los routers que realizan gestión del ToS para darlos prioridad o descartarlos si son incapaces de cursar el tráfico con las prestaciones requeridas por el flujo de datos. Al marcar un flujo de datos con características rígidas en términos de ancho de banda o retardo se da a entender al router que si no se consigue tramitar dicho tráfico con esos requisitos no servirá y se procede a descartarlo.  Assured Forwarding (AF) PHB [18]: El marcaje AF se utiliza en tráfico al que se desea priorizar frente al tráfico con prioridad estándar. Existen en total nueve tipos distintos de tráfico AF dependiendo de su nivel de prioridad y su caracterización en los bits S. Según [19], sólo determinados codepoints (valores del TOS) serán aceptados como tal en los routers, tratando el resto de combinaciones como tráfico por defecto bien convirtiendo el TOS a 0x00 ó simplemente ignorándolo. Todas las clases de tráfico vistas hasta el momento se pueden clasificar en la siguiente tabla: 64 Medidas experimentales Comandos lanzados en player 1 #Limpieza total de reglas iptables iptables -F iptables -t nat -F iptables -t mangle -F iptables -X #Trafico prioritario nivel 4 AF43 en DS iptables -t mangle -A OUTPUT -p udp --dport 5002 -j DSCP --set-dscp 34 #Generación de tráfico desde DS iperf -c 192.168.1.108 -u -b 100m -t 30 -l 200 -p 5002 Comandos lanzados en el player 2 #Limpieza total de reglas iptables iptables -F iptables -t nat -F iptables -t mangle -F iptables -X #Trafico sin marcar iptables -t mangle -A OUTPUT -p udp --dport 5002 -j DSCP --set-dscp 0 #Generación de tráfico desde el ordenador iperf -c 192.168.1.100 -u -b 100m -t 30 -l 200 -p 5001 El comportamiento del tráfico capturado se muestra en la siguiente figura: Tráfico total capturado en el canal 11, utilizado por la red Wi-Fi. Tráfico UDP sin marcar generado desde el ordenador Trafico UDP marcado AF43 generado desde el player 1 Figura 4-12: Medidas tomadas con un portátil en modo monitor a nivel 802.11 0 Kbytes 100 200 QoS con enlaces 802.11 65 En la Figura 4-13, se observa cómo domina el canal el tráfico UDP del player 1 marcado como tráfico de alta prioridad frente al tráfico sin marcar del ordenador. Es apreciable que cuando se produce un desvanecimiento en el cliente 802.11 usado por el player 1 para radiar se aprovecha por el ordenador para transmitir. Sin embargo, medidas que se realizaron posteriormente reflejan que en el cliente Wi-Fi del player el tráfico cursado siempre se está procesando como tráfico de alta prioridad. El cliente Wi-Fi usado por el player 1 se conecta a la red como “router en extensión de la red”, usando prestaciones de red distribuida WDS. En el estándar 802.11 se define que la comunicación entre puntos de acceso de la misma red en modo WDS debería hacerse por cable. No obstante, el dispositivo empleado en el caso analizado permite realizar este enlace por Wi-Fi, característica que lo convertía a efectos prácticos en un cliente Wi-Fi para cualquier dispositivo que use Ethernet cableado (player 1). Sin embargo, como esta prestación extra no se encuentra incluida en el estándar, el fabricante la implementó de modo que las comunicaciones entre APs de la misma red se produzcan siempre con la máxima prioridad a nivel 802.11, ignorando en todo momento el marcaje aplicado por el player 1. Esto resulta comprensible, puesto que al funcionar un router/ap en modo WDS, las comunicaciones con el router de la red deberían gozar de la mayor prioridad posible; puesto que se entiende que aglutina comunicaciones de otros usuarios hacia el router de la red. Existen otros dispositivos que funcionan como auténticos clientes Wi-Fi que se están analizando como alternativa. Un potencial candidato es el Pepwave surf on-the-go descrito brevemente en el Anexo. 4.4.2. Segundo escenario En el segundo escenario, se plantea analizar el grado de funcionamiento de EDCA a la hora de priorizar los flujos de datos del player frente a otros flujos de la red 802.11 de otros dispositivos. Se busca verificar que el marcado propuesto consigue que el sistema EDCA trate de forma diferente a los flujos de datos, dando mayor prioridad a los del player. Para ello se establecen transferencias de datos UDP desde el player y el ordenador hacia un servidor local de red con el fin de analizarlas y verificar que las transferencias del player con alta prioridad son capaces de conseguir mayor ancho de banda que las del ordenador. Figura 4-13: Escenario de pruebas para comprobar el funcionamiento de EDCA en caso de que exista tráfico de fondo sustancial de otro dispositivo de la red. 66 Medidas experimentales La transferencia de datos desde el player se realiza en diversos flujos que sobrepasan la capacidad del canal. Debe tenerse en cuenta que los paquetes UDP se generan con tamaño de datos reducido (200 bytes) para favorecer el efecto de la sobrecarga de 802.11 y facilitar la lectura gráfica de los resultados. sleep 10 && iperf -c 192.168.1.108 -u -b 5m -t 60 -l 200 -p 5002 & sleep 20 && iperf -c 192.168.1.108 -u -b 5m -t 50 -l 200 -p 5003 & sleep 0 && iperf -c 192.168.1.108 -u -b 5m -t 70 -l 200 -p 5004 & El marcaje de los paquetes se realiza utilizando iptables del player: iptables -t mangle -A OUTPUT -p udp --dport 5002 -j DSCP --set-dscp 46 iptables -t mangle -A OUTPUT -p udp --dport 5003 -j DSCP --set-dscp 34 iptables -t mangle -A OUTPUT -p udp --dport 5004 -j DSCP --set-dscp 26 Desde el ordenador se establece un único flujo de datos sleep 30 && iperf -c 192.168.1.108 -u -b 5m -t 20 -l 200 -p 5005 & La configuración de la tarjeta de red del ordenador durante las pruebas es la siguiente wlan0 IEEE 802.11bgn ESSID:"Ateire" Mode:Managed Frequency:2.412 GHz Access Point: 2C:B0:5D:D9:DB:37 Bit Rate=150 Mb/s Tx-Power=17 dBm Retry long limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:on Link Quality=51/70 Signal level=-59 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:26 Invalid misc:424 Missed beacon:0 Figura 4-14: Estado de la interfaz de red 802.11 del ordenador utilizado durante las pruebas QoS con enlaces 802.11 67 Los resultados de las pruebas pueden apreciarse en la siguiente figura: Figura 4-15: Resultados de las medidas del segundo escenario: Tráfico del player con distintas prioridades compaginado con tráfico de un ordenador de la misma red sin ningún tipo de prioridad. Tabla 4-8: Correspondencias empíricas entre CoS y DSCP en el segundo escenario PRIO 1 AC_VO PRIO 2 AC_VI PRIO 3 AC_BE PRIO 4 AC_BK DSCP CoS Disp. origen Puerto dst. 46 EF Player 1 5002 X 34 AF41 Player 1 5003 X 26 AF31 Player 1 5004 X 0 0 Ordenador 5005 X Existen varios aspectos a destacar de este escenario. En primer lugar, el tráfico EF no se trata localmente igual que en el ejemplo anterior y por lo tanto no se gestiona adecuadamente por la política de colas de este driver. En primer lugar cabe destacar el cambio de comportamiento del tráfico EF frente al tráfico AF31 y el tráfico Best Effort existente en la red. Esto puede deberse a un bug en el planificador WMM del driver. Por otro lado, confirmar que el tráfico AF41 sigue siendo el de mayor prioridad del player, pues en pequeños desvanecimientos del canal, este tráfico persiste en detrimento de AF31. El ordenador sólo transmite tráfico background frente al player que transmite flujos con niveles de prioridad superiores. De la gráfica se deduce que el ancho de banda empleado por los flujos es similar en AF41, AF31 y BE, por lo que pese a todo, se concluye que el player dispone de mayor canal disponible 500 Kbytes 1125 1250 875 1000 625 750 375 125 250 0 Tráfico total registrado por la interfaz Wi-Fi Tráfico enviado al puerto 5002 con campo DSCP 46 Tráfico enviado al puerto 5003 con campo DSCP 34 Tráfico enviado al puerto 5004 con campo DSCP 26 Tráfico enviado al puerto 5005 con campo DSCP 0 68 Medidas experimentales que el ordenador, pues aunque los flujos de datos están parejos (salvo el espurio inicial) la transferencia neta de información del player en total es mayor que la del ordenador. Por otro lado, el ordenador dispone de una tasa máxima de transferencia de 155 Mbps negociada con el AP mientras que el player sólo una tasa de 54 Mbps, y pese a ello el player ha sido capaz de transmitir mayor cantidad de información por lo que EDCA ha funcionado consiguiendo diferenciar el tráfico del player frente al del ordenador sin necesidad de configurar nada en el router. Sin embargo esa diferenciación en las distintas clases de tráfico del player no se produce tal y como se especifica en el estándar y debe tenerse en cuenta a la hora de efectuar el marcaje si se elije este chip WI-FI para trabajar con los players. Conclusiones Conclusiones 71 5. CONCLUSIONES En este documento se ha expuesto el funcionamiento de una red profesional de Digital Signage en la que tanto el player como el server se han diseñado para trabajar conjuntamente con ese cometido para ofrecer flexibilidad y escalabilidad. Esto permite reducir los problemas derivados del establecimiento manual de las conexiones y la conectividad en movilidad. Sin embargo, el sistema de conexiones empleado se encuentra con problemas de latencia debidos fundamentalmente a dos aspectos: La congestión en las comunicaciones tuneladas y los problemas derivados del acceso a Internet a través de hotspots o puntos de acceso Wi-Fi saturados. Para abordar la latencia de las comunicaciones tuneladas, se ha expuesto el funcionamiento de las conexiones entre el player y el servidor y se han propuesto medidas que mejoran puntualmente la latencia como minimizar el tráfico de control, emplear un sistema de distribución de contenidos en diferido, diferenciar el tráfico en la red local y emplear una versión modificada de OpenSSH que use UDP en las comunicaciones tuneladas. No obstante, la causa fundamental de la latencia elevada es la congestión que determinados flujos de datos del player (transferencias SFTP) causan en el resto de comunicaciones simultáneas entre el player y el servidor. Para evitar esto último se plantea el separar las sesiones SSH de las transferencias SFTP del resto de comunicaciones. De este modo se facilita el acceso al ancho de banda del resto de flujos aprovechando que cada sesión de SSH realiza control de congestión. Por otro lado, se observa que la congestión se puede llegar a evitar sin perjudicar el throughput regulando el buffer del cliente SFTP que manda la información. Este efecto se consigue de forma transparente sustituyendo el algoritmo Reno de control de congestión de TCP por Vegas. Este algoritmo limita la tasa de transferencia de cada flujo ajustando el ancho de ventana de contención TCP en base a la capacidad del canal estimada con los RTT de los ACK. La validez de TCP Vegas se pone de manifiesto en pruebas experimentales en las que se monitoriza el RTT de peticiones de echo tuneladas en un escenario en el que el player está transmitiendo datos vía SFTP. TCP Vegas evita que se produzca la congestión permitiendo que siempre exista ancho de banda disponible y la latencia se mantenga controlada. La latencia también puede depender en algunos casos del estado de la red Wi-Fi local, especialmente en lugares públicos donde el acceso se comparte como en hotspots, comercios, ferias, etc. En estas circunstancias se plantea la posibilidad de mejorar la conectividad de dispositivos DS mediante el empleo de EDCA, disponible en dispositivos 802.11 con capacidades WMM. Se ha propuesto utilizar un dispositivo USB que implemente estas funcionalidades y se han valorado en dos escenarios. En primer lugar se verifica la capacidad de priorizar entre varios flujos del mismo dispositivo y en segundo lugar se comprueba si es capaz de priorizar tráfico del dispositivo DS frente al existente en la red. Los resultados obtenidos indican que el desarrollo del driver y el hardware concreto pueden ser un problema, pues el comportamiento del mismo varía dependiendo del chip y fabricante y además pueden existir bugs de driver por resolver. Para evitar esto último se propone la utilización de clientes WIFI 802.11 con hardware y driver propietario incluido en el firmware que permitan a un player con interfaz Ethernet 802.3 conectarse por cable a este dispositivo y de forma transparente acceder a una red 802.11. Este cliente Wi-Fi, al tener capacidades WMM puede recibir paquetes marcados a nivel ToS y mapear su QoS a 802.11. Anexo: Dispositivos hardware Acrónimos 82 Acrónimos 83 7. ACRÓNIMOS Acrónimo Término AC Access Category AC_BE Access Category Best Effort AC_BK Access Category Background AC_VI Access Category Video AC_VO Access Category Voice ACK Acknoledgement ADSL Asymmetric Digital Subscriber Line AF Assured Forwarding AIFS Arbitration Inter-Frame Space AIFSN AIFS-Number AP Access Point B-ACK Block-ACKnowledgement BD Base de Datos BW BandWidth CCK Complementary Code Keying CTS Clear To Send CW Contention Window DCF Distributed Coordination Function DIFS DCF Inter-Frame Space DLS Direct Link Setup DS Digital Signage DSCP Differenciated Services Code Point E2E End to end ECN Explicit Congestion Notification EDCA Enhanced Distributed Channel Access EDGE Enhanced Data Rates for GSM Evolution EF Expedited Forwarding FPU Floating-Point Unit Gbps Gigabits per second GPIO General Purpose Input Output GPRS General Packet Radio Service GPU Graphics Processing Unit HCCA HCF Controlled Channel Access HCF Hybrid Coordination Function HTTP HyperText Transfer Protocol HTTPS HyperText Transfer Protocol Secure IP Internet Protocol LAN Local Area Network MAC Media Access Control Mbps MegaBits per second OFDM Orthogonal Frequency Division Multiplexing PCF Point Coordination Function 84 PHB Per Hop Behaviour PIFS DCF Inter-Frame Space QoS Quality of Service RTS Request To Send RTT Round-Trip delay Time SFTP Secure File Transfer Protocol SIFS Short Inter-frame Space SLA Service Level Agreement SoC System on Chip SSDP Simple Service Discovery Protocol SSH Secure SHell SSID Service Set IDentifier TCP Transmission Control Protocol TXOP Transmission Opportunity UDP User Datagram Protocol UPnP Universal Plug and Play USB Universal Serial Bus VLAN Virtual LAN VoIP Voice over Internet Protocol WDS Wireless Distribution System Wi-Fi Wireless Fidelity WMM Wi-Fi MultiMedia WMM-SA WMM Scheduled Access Bibliografía Bibliografía 87 8. BIBLIOGRAFÍA [1] C. Santander, «End-to-end available bandwidth estimation and monitoring», University of South Florida, 2009. [2] O. Hondaa, H. Ohsakia, M. Imasea, M. Ishizukaba, J. Murayama, «Understanding TCP over TCP: Effects of TCP Tunneling on», IEIC Technical Report (Institute of Electronics, Information and Communication Engineers), vol. 104, nº 438, pp. 108-122, 2004. [3] M. Karlsson, A. Habib, «SSH over UDP», University of Gothenburg, Sweden, 2012. [4] T. Ylonen, C. Lonvick, Ed., «RFC4254: The Secure Shell (SSH) Connection Protocol», 2006. http://tools.ietf.org/html/rfc4254. [5] J. Haslam, «Dtrace introduction», Oracle, Sun Microsystems, Noviembre de 2011. https://wikis.oracle.com/display/DTrace/Introduction. [6] Foxtrot Systems Ltd, «Repositorio dtrace para Linux», 9 de Octubre de 2012. https://github.com/dtrace4linux. [7] S. Sanfilippo, «hping.org», Noviembre de 2005. http://www.hping.org/. [8] S. Ostermann, «tcptrace.org», Abril de 2003. http://www.tcptrace.org/. [9] Lawrence S. Brackmo, Larry L. Petterson, «TCP Vegas: End to end congestion avoidance on a Global Internet», vol. 13, nº 8, pp. 1465-1480, Octubre de 1995. [10] Richard J. La, Jean Walrand, Venkat Anantharam, «Issues in TCP Vegas», Berkley, California, 2001. [11] G. Smith, DSP Group, «802.11 QoS Tutorial», 10 de Noviembre de 2008. http://www.ieee802.org/1/files/public/docs2008/avb-gs-802-11-qos-tutorial-1108.pdf. [12] IEEE Computer Society, «IEEE Std 802.11e™-2005», 11 de Noviembre de 2005. http://standards.ieee.org/getieee802/download/802.11e-2005.pdf. [13] Wi-Fi Alliance, «Wi-Fi CERTIFIED™ for WMM™ - Support for Multimedia Applications with Quality of Service in Wi-Fi® Networks», 1 de Septiembre de 2004. http://www.wifi.org/files/wp_1_WMM%20QoS%20In%20Wi-Fi_9-1-04.pdf. [14] K. Nichols, S. Blake, F. Baker, D. Black, «RFC2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», Diciembre de 1998. http://tools.ietf.org/html/rfc2474. [15] K. Ramakrishnan, S. Floyd, D. Black, «RFC3168: The Addition of Explicit Congestion Notification (ECN) to IP», http://tools.ietf.org/html/rfc3168. [16] The Linux Foundation, «Queues for QoS 802.11e/WMM EDCA», http://linuxwireless.org/en/developers/Documentation/mac80211/queues. [17] IETF Network Working Group, «RFC3246: An Expedited Forwarding PHB (Per-Hop Behavior)», http://tools.ietf.org/html/rfc3246. [18] IETF Network Working Group, «RFC2597: Assured Forwarding PHB Group», Junio de 1999. http://tools.ietf.org/html/rfc2597. [19] D. Grossman, Motorola, Inc., «RFC3260: New Terminology and Clarifications for Diffserv», Abril de 2002. http://tools.ietf.org/html/rfc3260. [20] Cisco Systems, «Unified Wireless QoS», 88 http://www.cisco.com/en/US/docs/solutions/Enterprise/Mobility/emob41dg/ch5_QoS.html#wp10514 21. [21] Peter P. Waskiewicz Jr.,LAN Access Division, Intel Corp., «Converged Networking in the Data Center», de Linux Symposium, Montreal, Quebec Canada, 2009. [22] T. Graf, G. Maxwell, R. van Mook, M. van Oosterhout, P. Larroy, «Linux Advanced Routing & Traffic Control», 19 de Mayo de 2012. http://lartc.org/howto/lartc.qdisc.filters.html. [23] Intel Corporation (e1000-eedc), «Data Center Bridging (DCB) for Intel® Network Connections», 4 Diciembre de 2010. ftp://ftp.supermicro.com/CDR-NIC_1.22_for_Add- on_NIC_Cards/Intel/LAN/APPS/FCOEBOOT/DOCS/dcb.htm. [24] Wireshark, «Wireshark VLAN capture setup», http://wiki.wireshark.org/CaptureSetup/VLAN. [25] DD-WRT, «Supported devices», http://www.dd-wrt.com/wiki/index.php/Supported_Devices. [26] Thatexplainsalot, «Use Wireshark And DD-WRT Router Firmware To Imitate Port Monitoring On A Router Switch Port», http://thatexplainsalot.com/?p=292. [27] Broadcom, «Low-Power PCI Express® HD Media Processor», http://www.broadcom.com/products/Consumer-Electronics/Netbook-and-Nettop- Solutions/BCM70015 . [28] Broadcom, «High Definition 1080p Embedded Multimedia Applications Processor», http://www.broadcom.com/products/BCM2835. [29] L. Upton, «Raspbian sneak peek from Dom – performance increases up the wazoo!», http://www.raspberrypi.org/archives/1565. [30] «Omxplayer builds», http://omxplayer.sconde.net/. [31] The Guardian, «Raspberry Pi demand running at '700 per second'», 5 de Marzo de 2012. http://www.guardian.co.uk/technology/2012/mar/05/raspberry-pi-demand.