MPTCP Cruz-Mora.pdf

MP-TCP Autores: Diego Cruz Rubén Mora

3

MP-TCP

ÍNDICE

OBJETIVOS I. INTRODUCCION II. ESCENARIO DE REFERENCIA II.1. METAS FUNCIONALES II.2. METAS DE COMPATIBILIDAD II.3. III.4.

METAS DE SEGURIDAD SEÑALIZACIÓN

III. ARQUITECTURA BÁSICA PARA MP-TCP III.1. DESCOMPOSICIÓN FUNCIONAL DE MP-TCP III.2.

DECISIÓN DE DISEÑO DE ALTO NIVEL

III.3.

BUFFER

III.4.

SEÑALIZACIÓN

III.5.

MANEJO DE CAMINO

III.6.

IDENTIFICACIÓN DE CONEXIÓN

III.7.

CONTROL DE LA CONGESTION

III.8.

SEGURIDAD

IV. COMPARACION CON TCP ESTANDAR V. MEJORAS INTRODUCIDAS CON MP-TCP V.1.

MEJORA EN EL RENDIMIENTO

V.2. MEJORA EN TROUGHPUT V.3.

RETARDO

V.4.

CAPACIDAD DE RECUPERACION DE LA RED (RESILIENCE)

VI. CONSIDERACIONES DE SEGURIDAD

VII.

VI.1.

ATAQUES TIPO FLOODING

VI.2.

ATAQUES TIPO SECUESTRO DE CONEXIÓN (HIJACKING)

VI.3.

ATAQUE MAN IN THE MIDDLE (MITM)

CASOS DE USO E IMPLEMENTACIONES

VIII. CONCLUSIONES IX.

REFERENCIAS Y BIBLIOGRAFÍA

MP-TCP

4

OBJETIVOS -

Conocer el funcionamiento del protocolo MP-TCP.

-

Describir la arquitectura en la que se basa el funcionamiento de MP-TCP.

-

Hacer una comparación con TCP actual y resaltar ventajas y desventajas.

-

Describir las aplicaciones actuales.

I.

INTRODUCCIÓN

Con la evolución del Internet, la demanda de los recursos incrementa, pero frecuentemente estos recursos (en especial, ancho de banda) no pueden ser completamente utilizados debido a las restricciones del protocolo en los sistemas finales dentro de la red. Si estos recursos se los podría usar correctamente, la experiencia del usuario final podría ser enormemente mejorada. Estas mejoras también reducirían la necesidad de gastos en infraestructura de la red.

El transporte Multipath permite alcanzar algunas metas del poleo de recursos haciendo uso simultáneamente de caminos disjuntos (o parcialmente disjuntos) a través de la red. Los dos principales beneficios de transporte multipath son los siguientes: 

Incrementar la resistencia de la conectividad proveída por los múltiples caminos, protegiendo usuarios finales de la falla de uno.



Incrementar la eficiencia del uso de recursos, e incrementar la capacidad de la red disponible para los usuarios finales.

MP-TCP es la versión modificada de TCP que implementa transporte multipath y logra estas metas por poleo de caminos múltiples dentro de una conexión de transporte, transparentemente para la aplicación. MP-TCP tiene como preocupación principal el uso múltiple de caminos extremo a extremo, donde uno o ambos de los usuarios finales tienen múltiples tarjetas. Esto puede tener aplicaciones también donde los caminos múltiples existen dentro de una red y pueden ser manipulados por un usuario final, como usando diferente número de puertos con Equal Cost MultiPath (ECMP).

5

MP-TCP

Un objetivo de MP-TCP para ganar un despliegue de gran escala reconociendo la importancia de la aplicación y compatibilidad de la red.

A continuación se pretende describir como objetivos: (i) Describir metas para un transporte multipath, metas para las que MP-TCP fue diseñado; (ii) Presentar la arquitectura básica para diseños MP-TCP (iii) decisiones de alto nivel hechas en el desarrollo de MPTCP con sus implicaciones.

II.

ESCENARIO DE REFERENCIA.

El diagrama presentado en la figura 1, ilustra el escenario de uso típico para MPTCP. Dos hosts, A y B, están comunicándose entre ellos. Estos hosts tienen multi-tarjeta y múltiples direcciones, proveyendo dos conexiones disjuntas a internet. Las direcciones de cada hosts están referidas a A1, A2, 1 y B2. Por lo que hay 4 caminos diferentes entre 2 hosts: A1-B1, A1-B2, A2-B1, A2-B2.

Figura 1: Escenario de uso de MP TCP Simple

El escenario podría tener cualquier número de direcciones (1 o más) en cada host, tantas como caminos disponibles entre hosts se quieran. Los caminos creados por esta combinación de direcciones a través de Internet no necesitan ser enteramente disjunto.

II.1. 

METAS FUNCIONALES.

Mejorar el Throughput: MP-TCP debe soportar el uso concurrente de múltiples caminos. Para lograr los incentivos mínimos de desempeño para el despliegue, una conexión MP-TCP sobre múltiples caminos debe alcanzar el throughput no peor que una conexión TCP simple sobre el mejor camino elegido.

MP-TCP



6

Mejorar Resistencia: MT-TCP debe soportar el uso de múltiples caminos intercambiables para propósitos de resistencia, permitiendo que los segmentos se envíen y reenvíen por cualquier camino disponible. Así en el peor de los casos, el protocolo debe ser resistente no menos que un TCP regular de camino único.

La distribución del tráfico a través de caminos disponibles y respuestas a la congestión se hacen acorde con los principios de poleo de recursos, un efecto secundario de lograr estas metas es que extiende el uso de MP-TCP sobre Internet debe mejorar sobre la utilidad de la red, cambiando la carga lejos de cuellos de botella congestionados y tomando ventaja de la posibilidad de esparcir la capacidad donde sea.

Además, MP-TCP debe tener la característica de negociación automática de su uso. Un host soportando MP-TCP que requiere que otro host haga lo mismo debe poder detectar de forma fiable si el host de hecho puede soportar la extensión requerida, usándolas si puede y caso contrario automáticamente regresa a la conexión TCP de camino único.

II.2.

METAS DE COMPATIBILIDAD.

Además de cumplir con las metas funcionales MP-TCP debe cumplir con las siguientes categorías de metas de compatibilidad. 

Compatibilidad de Aplicación.

MP-TCP debe seguir el mismo modelo de servicio que TCP, en orden, confiable, entrega orientada a byte. Además, una conexión MP-TCP debe proveer la aplicación con un throughput o resistencia no peor que la que se espera corriendo en una conexión TCP simple sobre cualquiera de los caminos disponibles. MP-TCP no debe, sin embargo, puede ser capaz de proveer el mismo nivel de consistencia del troughput y latencia que una conexión TCP simple.

Para una sesión regular TCP es posible sobrevivir hoy a muchos de los quiebres en conectividad reteniendo el estado en los hosts finales antes que ocurra el timeout.

7



MP-TCP

Compatibilidad de la Red.

Requiere que la extensión multipath para retener la compatibilidad TCP con el Internet existe hoy, incluyendo hacer esfuerzos razonables para ser capaz de atravesar cajas intermedias predominantes, como firewalls, NATs y proxies para mejorar el rendimiento. MP-TCP debe preservar fate-sharing sin hacer suposiciones acerca del comportamiento de la caja intermedia. MP-TCP debe retroceder a TCP regular si existen incompatibilidades insuperables para la extensión multipath en el camino.

Las modificaciones para soportar MP-TCP permanece en la capa de transporte, MP-TCP debe trabajar con IPv4 y IPv6.

Como corolario para ambas compatibilidades, la arquitectura debe permitir nuevos flujos MP-TCP para coexistir con los flujos TCP de camino único existentes, compitiendo por el ancho de banda no muy agresivamente ni débilmente. El uso de caminos múltiples no debe afectar a los usuarios que usan TCP simple en cuellos de botella compartidos, más allá del impacto que ocurriría de otro flujo TCP simple. Flujos MP-TCP en cuellos de botella compartidos debe compartir el ancho de banda entre cada uno de forma equitativa.

II.3.

METAS DE SEGURIDAD.

La extensión de TCP con capacidades mutipath traerá un número de nuevas amenazas, que se analizan posteriormente, por esto, las metas de seguridad de MP-TCP es proveer un servicio no menos seguro que el regular TCP. Esto se logrará a través de la combinación de mecanismos de seguridad TCP existentes. Y de la protección contra las nuevas amenazas multipath identificadas.

III.

ARQUITECTURA BÁSICA PARA MP-TCP.

El nuevo modelo de Internet descrito se basa en ideas propuestas en Tng (“Transport nextgeneration”).

MP-TCP

8

Figura 2: Descomposición de las funciones de transporte

Tng divide libremente la capa de transporte en capa de “orientada a la aplicación” y “orientada a la red”, como muestra la figura 2. La capa orientada a la aplicación “Semantic” implementa funciones impulsadas primordialmente por preocupaciones de soporte y protección de la comunicación extremo a extremo de la aplicación, mientras que la capa de red-orientada “Flow+Endpoint” implementa funciones como identificación de fin de punto (usando número de puertos) y control de congestión. Estas funciones de redorientadas, mientras que tradicionalmente se encuentra en la ostensible capa de transporte “extremo a extremo”.

El diseño de arquitectura MP-TCP sigue la descomposición de las Tng. MP-TCP, el cual provee compatibilidad de aplicación a través de la preservación de semántica TCP-like de ordenamiento global de aplicación de datos y confiabilidad, es una instanciación de la capa semántica “orientada a la aplicación”; mientras el subflujo del componente TCP, el cual provee compatibilidad de la red por aparición y comportamiento como flujo TCP en la red, es una instanciación de la capa Flow+Endpoint “orientada a la red”.

Como extensión del protocolo TCP, MP-TCP reconoce explícitamente cajas intermedias (middleboxes) en su diseño y especifica un protocolo que opere a 2 escalas: el componente opera extremo a extremo, mientras que permite al componente TCP operar segmento por segmento.

III.1. DESCOMPOSICIÓN FUNCIONAL DE MP-TCP. MP-TCP hace uso de sesiones estándar TCP “aparenta que está en la red”, como término “subflujo” para proveer de transporte subyacente por camino, y así mantiene la

9

MP-TCP

compatibilidad de la red deseada. La información MP-TCP específica es llevada en forma compatible TCP, este mecanismo es separado de la información actual que es transferida que podría evolucionar en revisiones futuras. En la figura se puede ilustrar la arquitectura en capas.

Figura 3. TCP Tradicional vs MP-TCP

Situada debajo de la aplicación la extensión MP-TCP para manejar múltiplos subflujos TCP debajo de ella. Para lograr esto debe implementar las siguientes funciones: 

Manejo de camino: función para detectar y usar los múltiples caminos entre dos hosts. MP-TCP usa la presencia de múltiples direcciones IP en uno o ambos de los hosts como un indicador de esta. Las características del manejo de caminos del protocolo MP-TCP son

los mecanismos para dirección de señal alternativa para hosts, y

mecanismos para la creación de nuevos subflujos unidos a una conexión existente MPTCP. 

Programación del paquete: esta función rompe el byte stream recibido de la aplicación en segmentos para ser transmitidos en uno de los subflujos disponibles. El diseño MP-TCP hace uso de paso de secuencia de datos, asociando segmentos enviados en diferentes subflujos para la numeración de la secuencia del nivel de conexión, permitiendo a los segmentos enviados en diferentes subflujos ser correctamente reordenados en el receptor. El programador de paquetes es dependiente de información acerca de disponibilidad de caminos expuestos por el componente de manejo de caminos, y luego hace uso de los subflujos para transmitir segmentos encolados. Esta función es también responsable para el reordenamiento del nivel de

MP-TCP

10

conexión en la recepción de paquetes de los subflujos TCP, acorde al mapeo de secuencia de datos adjunto. 

Interfaz de Subflujo (TCP camino único): un componente de subflujo toma segmentos del componente de programación de paquetes y los trasmite sobre el camino específico, asegurando la entrega detectable para el host.

MP-TCP usa TCP por debajo de la compatibilidad de la red; TCP asegura la entrega en orden y confiable. TCP añade sus propios números de secuencia a los segmentos; estos suelen detectar y retransmitir pérdida de paquetes en la capa de subflujo. En recepción, el subflujo pasa sus datos reensamblados al componente de programación de paquetes para reensamblar a nivel de conexión; el mapeo de secuencia de datos desde el componente de programación de paquetes del emisor permite el reordenamiento del byte stream entero. 

Control de Congestión: Esta función coordina el control de la congestión a través de subflujos. Este algoritmo de congestión debe asegurar que la conexión MP-TCP no tome injustamente más ancho de banda que un flujo TCP de camino simple en el cuello de botella compartido.

Estas funciones deben juntárselas de la siguiente manera. El administrador de caminos busca después del descubrimiento (y si es necesario, inicialización) de múltiples caminos entre dos hosts. El programador de paquetes luego recibe el stream de datos desde la aplicación destinada por la red, y se encarga de las operaciones necesarias en este (como segmentación de datos en segmentos de nivel de conexión, y añadiendo un número de secuencia al nivel de conexión antes de enviarlo en el subflujo. El subflujo luego añade su propio número de secuencia, ACK’s y los pasa a la red. El subflujo recibido reordena los datos (si es necesario) y los pasa al componente programador de componentes, que realiza el reordenamiento a nivel de la conexión y envía el stream de datos a la aplicación. Finalmente, el componente de control de la congestión existe como parte del programador de paquetes, para programar cual segmento deberá enviarse a que tasa y con cual subflujo.

11

MP-TCP

III.2.

DECISIÓN DE DISEÑO DE ALTO NIVEL.

Aparentemente hay un amplio rango de decisiones cuando estas diseñando una extensión multipath de TCP. Sin embargo, se menciona la siguiente línea de diseño de alto nivel que se basa en la arquitectura básica. 

Secuencia de numeración.

TP-TCP usa dos niveles de espacios de secuencias: Un número de secuencia a nivel de conexión y otro número de secuencia para cada subflujo. Esto permite segmentación a nivel de conexión y reensamblamiento y retransmisión de la misma parte del espacio de secuencia de niel de conexión en diferente espació de secuencia de nivel de subflujo.

La aproximación alternativa usaría un número de secuencia de nivel de conexión simple, con el cual se envía en múltiples subflujos. Esto tiene dos problemas: primero el subflujo individual aparecerá para la red como sesión TCP con lagunas en los espacios de secuencia; esto puede molestar algunas cajas intermedias como lo son los sistemas de detección de intrusos, o ciertos proxies transparentes, e iría en contra de la meta de compatibilidad de la red. Segundo, el emisor no sería capaz de atribuir paquetes perdidos o recepciones por el camino correcto cuando el mismo segmento es enviado en múltiples caminos.

El emisor debe ser capaz de decir al receptor como reesnamblar los datos, para entregarlos a la aplicación. Para lograr esto el receptor debe determinar cómo los datos de nivel de subflujo (llevando números de secuencia de subflujo) mapea a nivel de conexión. Esto es referido a “mapeo de secuencia de datos”. Este mapeo puede ser representado como una tupla de (número de secuencia de datos, número de secuencia de subflujo tamaño),

Una opción para el mapeo de la señal d secuencia de datos podría ser utilizar los campos existentes en el segmento TCP (como número de secuencia de subflujo, tamaño) y añadir solamente el número de secuencia de datos en cada segmento, por instancia, como una opción TCP. Esto sería vulnerable, sin embargo, para las cajas intermedias que re segmenta o ensambla datos, no hay comportamiento específico para incorporar opciones TCP. Si una señalada (número de secuencia de datos, tamaño), esta seguirá siendo vulnerable para cajas

MP-TCP

12

intermedias que incorporan segmentos y no entienden señalización MP-TCP así que no coescribirá las opciones correctamente.

Por este problema potencial, la decisión de diseño tomada en el protocolo MP-TCP es que cuando sea un mapeo para subflujo de datos necesita ser transportado al otro host, los tres pedazos de datos (sec. de datos, sec. de subflujo y tamaño) deben enviarse. Para reducir el encabezado, podría ser permisible para el mapeo para ser enviado periódicamente y cubierto más que en un segmento simple. Además la experimentación es requerida para determinar que negociación existe respecto a la frecuencia a la que el mapeo debería ser enviado. Esto también podría ser excluido enteramente en el caso de una conexión anterior más que un subflujo utilizado, donde el espacio de secuencia de nivel de datos y nivel de subflujo es el mismo. 

Retransmisiones y Fiabilidad.

Las características de reconocimiento MP-TCP en el nivel de conexión como en el nivel de subflujo, están para proveer servicio de robustez a la aplicación.

Bajo comportamiento normal, MP-TCP podría usar el mapeo de secuencia de datos y subflujos ACKs para decidir cuándo un segmento de nivel de conexión fue recibida. La transmisión de ACKs TCP para un subflujo son manejadas enteramente al nivel de retransmisión de nivel de subflujo. Esto tiene cierta implicación en semánticas extremo a extremo. Esto significaría que una vez el segmento es reconocido en el nivel de subflujo, no podrá ser descartado en el buffer de re-orden en el nivel de conexión. Segundo, diferente al estándar TCP, un receptor no puede simplemente desechar segmentos fuera de orden si necesita (por ejemplo, debido a la presión de memoria. Bajo ciertas circunstancias, puede ser deseable para desechar segmentos después de reconocerlos en el subflujo pero antes de entregarlos a la aplicación, y esto puede ser facilitado por un reconocimiento a niel de conexión.

Además, es posible concebir para que en algunos casos donde el reconocimiento de nivel de conexión pueda mejorar la robustez.

13

MP-TCP

Por lo tanto, para proveer una solución TCP multipath completamente robusta, a MP-TCP para uso en Internet público debe tener la característica de reconocimiento explícito de nivel de conexión, adicionalmente para reconocimientos de nivel de subflujo. El reconocimiento de nivel de conexión sería solamente requerido por la señal cuando reciba una ventana de avanzar.

En cuanto a retransmisiones, estas deben ser posibles para un segmento para ser retransmitida en diferentes subflujos desde el que fue originalmente enviado. Esto es principal para mantener la integridad durante fallas de subflujo temporales o permanentes y esto es permitido por el número de espacios de secuencia duales.

La programación de retransmisiones tendrá impacto significante en la experiencia de los usuarios MPTCP. La actual especificación MP-TCP sugiere que datos extraordinarios en subflujos que tienen timeout deben ser re-programador para transmisión en diferentes subflujos. Este comportamiento logra minimizar la desorganización cuando un camino se rompa, y usa el primer timeout como indicador. Versiones más conservadoras sería usar un segundo o tercer timeout para el mismo segmento.

Típicamente, rápida retransmisión en un subflujo individual no disparará retransmisiones en otro subflujo, además esto puede ser deseable en ciertos casos, por ejemplo, para reducir los requerimientos de buffer de recepción. Sin embargo, en todos los casos con retransmisiones en diferentes subflujos, los segmentos perdidos deben todavía ser enviados en el camino que se perdieron. Esto se cree necesario para mantener la integridad del subflujo. Si se hace esto, se pierde un poco de eficiencia.

III.3.

BUFFERS.

Para asegurar la entrega en orden, MP-TCP debe usar un buffer de recepción al nivel de conexión, donde los segmentos son colocados hasta que son ordenados y pueden ser leídos por la aplicación.

En MP-TCP, el receptor debe tener suficiente buffering para almacenar todos los datos hasta que el segmento perdido sea retransmitido y alcance el destino.

MP-TCP

14

El peor de los casos sería cuando el subflujo con el mayor RTT/RTO (Round-Trip Time or Retransmission TimeOut) experimenta un timeout; en este caso, el receptor tiene que poner la data de todos los subflujos en el buffer por la duración del RTO. Sería necesario el búfer de recepción a nivel de conexión más pequeño que podría ser necesitado para evitar el estancamiento con fallas de subflujo es

Sum(BW_i)*RTO_max,

Donde, BW_i = ancho de banda para cada subflujo RTO_max es el RTO más largo a lo largo de todos los subflujos.

Esto es un orden de magnitud más que el búfer de recepción requerido para una conexión simple, y es probablemente también costosa para propósitos prácticos. Uno requerimiento más sensible es para evitar estancarse en ausencia de timeouts. De ahí lo recomendado es que el búfer de recepción sea.

2*sum(BW_i)*RTT_max,

Donde, RTT_max es el RTT más largo a lo largo de todos los subflujos.

Este tamaño de buffer asegura que los subflujos no se estanquen cuando hay retransmisiones rápidas disparadas en cualquier subflujo.

El tamaño del búfer resultante debe ser lo pequeño suficiente para uso práctico.

Buffer del envío: el recomendado es el mismo tamaño que el recomendado para recepción. Esto es porque el emisor debe almacenar localmente los segmentos enviados pero no reconocidos por el nivel de conexión ACK. El tamaño del búfer de envío importa particularmente para hosts que mantienen un largo número de conexiones en marcha. Si el búfer de envío requerido es muy largo, un host puede escoger solamente enviar datos en los subflujos rápidos, usando el subflujo lento solamente en caso de falla.

15

III.4.

MP-TCP

SEÑALIZACIÓN

Como MP-TCP usa TCP, sus mecanismos de transporte de subflujos, en conexiones MPTCP también inician como una conexión TCP simple. Sin embargo, esto debe señalar al peer que soporta MP-TCP y desea usar esa conexión. Además se requiere señalización durante la operación de la sesión MPTCP, como para reensamblar a lo largo de múltiples subflujos, y para información del otro host acerca de otra dirección IP disponible.

El protocolo MP-TCP diseñado usaría opciones TCP para esta señalización adicional, con estos mecanismos, la señalización requerida para operar MP-TCP es transportado separadamente de los datos, permitiendo que sea creado y procesado por separado del data stream, y reteniendo la compatibilidad de arquitecturas con entidades de la red.

III.5.

MANEJO DE CAMINOS

Actualmente, la red no expone diversidad de caminos entre pares de direcciones IP. Para alcanzar diversidad de caminos en las redes IP de hoy, en el caso típico, MP-TCP usa múltiples direcciones en uno o dos hosts para inferir diferentes caminos a lo largo de la red. Se espera que estos caminos, no sean necesarios mientras no se sobrepongan, serían suficientemente disjuntos para permitir multipath para lograr mejorar el throughput y robustez. El uso de múltiples direcciones IP es un simpe mecanismo que no requiere características adicionales en la red.

Múltiples diferentes pares de direcciones (origen, destino) serían usados como caminos selectores en la mayoría de los casos. Sin embargo, cada camino será identificado por un estándar five-tuple, el cual puede permitir la extensión de MP-TCP para usar puertos como direcciones para seleccionar el camino. Esto permitirá a los hosts usar balanceo de carga basado en puerto con MPTCP.

Para aumentar la oportunidad de éxito se configuran subflujos adicionales, y el host debe ser capaz de añadir nuevos subflujos para conexiones MP-TCP, MPTCP debe ser capaz de manejar caminos que aparezcan y desaparezcan durante el tiempo de vida de la conexión. El manejo de caminos es una función separada del programador de paquetes, interfaz de subflujo y funciones de control de congestión de MP-TCP, sería factible reemplazar el

MP-TCP

16

diseño basado en direcciones IP con un mecanismo de selección alternativa de caminos, sin cambios significativos en los otros componentes funcionales. En la figura 4. Se observan los caminos posibles para una conexión entre un cliente y un servidor, cada dispositivo con dos interfaces de red diferentes.

Figura 4. Caminos Disponibles Conexión Cliente - Servidor

III.6.

IDENTIFICACIÓN DE CONEXIÓN.

Como una conexión MP-TCP no se limita al tradicional 5-tuple (dirección y puerto origen, dirección y puerto destino, número de protocolo) para la entereza de su existencia, es deseable proveer un nuevo mecanismo para la identificación de la conexión sería muy útil tener un único identificador con el cual se asocien los múltiples subflujos.

Cada conexión MP-TCP requiere un identificador de conexión en cada host, el cual es único localmente dentro del host. La conexión MP-TCP será identificada por los 5-tuple del primer subflujo TCP. MP-TCP no debe ser usado para aplicaciones que requieren unirse a una interfaz o dirección específica, donde las aplicaciones toman decisiones deliberadas del camino en uso.

17

III.7.

MP-TCP

CONTROL DE LA CONGESTION

El control de la congestión en presencia de múltiples trayectos significa que los sistemas adquieren un papel que se asocia normalmente con el enrutamiento, es decir, trasladar el tráfico en caminos que eviten puntos de congestión, de acuerdo a las trayectorias o rutas que tenga disponible. Cuando se cambia un flujo de datos se cambia a una ruta menos congestionada la tasa de pérdidas en el nuevo camino aumentará y en el anterior disminuirá, el resultado global con muchos trayectos es que la tasa de perdida de una red tiende a equilibrarse. Esto es una forma de balanceo de carga.

El control de la congestión en un ambiente MPTCP debe ser diseñado para lograr una asignación equitativa de los recursos, por ejemplo, si un flujo mulipath tiene 4 caminos disponibles y todos ellos tienen que pasar por el mismo cuello de botella, si se ejecuta simplemente un mecanismo para evitar congestión en cada ruta independiente, entonces se perderá 4 veces los flujos. La idea de poder trasladar tráfico entre diferentes caminos es que se pueda tener una determinada cantidad de tráfico extremo a extremo y que se compense las tasas bajas de una ruta con el mayor tráfico en otras.

Hay tres metas que los algoritmos de control de la congestión usados en la implementación MPTCP: mejorar el throughput; no afectar a otros usuarios de la red; y balance de la congestión alejando tráfico de los caminos más congestionados. Para lograr estas metas, los algoritmos de control de la congestión en cada subflujo deben estar acoplados en alguna manera.

III.8.

SEGURIDAD.

Se identifican tres requerimientos de seguridad. Un MP-TCP multi-direccionado debe ser capaz de hacer lo siguiente:

a. Proveer un mecanismo para confirmar que las partes en un handshake de subflujo son las mismas como en la configuración de la conexión original. b. Proveer la verificación que los peer pueden recibir tráfico en la nueva dirección antes de añadirla.

MP-TCP

18

c. Proveer protección contra la reproducción.

Mecanismos adicionales han sido desplegados como parte de la pila estándar TCP para proveer resistencia para ataques de Denial-ofXervice (DoS). Por ejemplo, hay varios mecanismos para proteger contra ataques de reseteo TCP, y TCP Multipath debe continuar para soportar una protección similar. Además TCP SYN cookies se desarrollaron para permitir al servidor TCP diferir entre la creación del estado de la sesión del estado SYN_RCVD, y permanece sin estado hasta alcanzar el estado ESTABLISHED. MP-TCP debe, idealmente, continuar proveyendo la funcionalidad y como mínimo evitar la carga computacional significativa antes de alcanzar el estado ESTABLISHED.

Esto debe ser notado:

a) El uso de opciones TCP significativamente limitan la cantidad de información que puede ser llevada en el handshake. b) La necesidad para trabajar a través de cajas intermedias resulta en la necesidad de manejar la mutabilidad de paquetes. c) El deseo de portar un “break-before-make”, se alcanza añadiendo subflujos (dentro de un limitado período de tiempo) implica que un host no puede confiar en el uso de subflujos preexistentes para soportar la suma de un nuevo.

IV.

COMPARACION CON TCP ESTANDAR.

TCP es un protocolo de nivel de transporte, es un protocolo orientado a la conexión, es decir, establece (negocia) una conexión antes de transmitir los datos y fiable porque asegura que la información sea recibida sin errores y en el mismo orden que se transmitieron (hace retransmisiones), también proporciona mecanismos para distinguir entre diferentes servicios o aplicaciones dentro de una misma maquina a través de los puertos. TCP está documentado por el IETF en el RFC 793. En la siguiente figura se observa el proceso para establecer una conexión que usa TCP

19

MP-TCP

Figura 5. Establecimiento conexión TCP

En un kernel que tenga habilitado MPTCP, los componentes TCP se reemplazarán por componentes MPTCP y subflujos TCP para cada interfaz, los componentes TCP reciben los datos de una aplicación (La aplicación no necesita ser modificada), entonces MPTCP divide los datos en múltiples segmentos que se convertirán en subflujos TCP. Cada uno de estos subflujos se comporta como una conexión TCP normal en la red. MPTCP puede manejar rutas de diferente ancho de banda porque implementa un mecanismo de control de la congestión a través de los subflujos, estos mecanismos garantizan que si hay congestión en alguna ruta, el tráfico sea desviado por otro camino que presente menor congestión. Se hace balanceo de carga en la red.

En la figura 6. Se aprecia el proceso para realizar una conexión utilizando MPTCP

MP-TCP

20

Figura 6. Establecimiento conexión varios flujos con MP-TCP

Los componentes MPTCP realizan tres funciones  Se encargan de la gestión de rutas mediante la detección y el uso de múltiples caminos desde un nodo origen a un nodo destino, cuando una conexión se establece los extremos realizan la negociación de direcciones IP alternativas que serán las rutas adicionales.  Divide el flujo de datos recibidos de la aplicación en múltiples segmentos y los transmite por uno de los sub flujos disponibles. Estos segmentos estarán numerados para que al recibirlos se puedan ordenar correctamente y reconstruir los datos originales.  Implementa control de congestión, hace balanceo de carga sobre los sub flujos (traslada el tráfico a la ruta menos congestionada)

En la siguiente figura se ilustra las diferencias en las capas superiores del modelo TCP/IP con la implementación de MPTCP

21

MP-TCP

Figura 7. Capas superiores modelo TCP/IP

La utilización del nuevo protocolo supondrá ua serie de mejoras a las prestaciones de la red, que se traduce en una mejor calidad de experiencia de los usuarios. En el siguiente apartado se hará una breve descripción de estos beneficios.

V.

MEJORAS INTRODUCIDAS CON MPTCP

V.1. MEJORAS EN EL RENDIMIENTO Uno de los objetivos al añadir multicaminos a TCP es el de mejorar el rendimiento de una conexión de transporte haciendo balanceo de carga distribuido sobre sub flujos separados a través de caminos diferentes. Es también objetivo explícito de MPTCP el de proveer una conexión que funcione al menos igual de bien como cuando se tiene un solo camino TCP. A continuación se detalla los efectos en el rendimiento con MPTCP desde el punto de vista de una aplicación:

V.2.

MEJORA EN TROUGHPUT

La mejora en el rendimiento más obvia que se puede esperar al implementar MPTCP es un aumento en el troughput, ya que MPTCP agrupará más de un camino (cuando sea posible)

MP-TCP

22

entre dos puntos finales. Esto usualmente provee un ancho de banda más grande para una aplicación, aunque pueden existir excepciones debido al control dinámico de la congestión. Por ejemplo, si se pone en marcha un sub flujo en un periodo corto de tiempo, el troughput puede ser menor que el óptimo teórico. Si hay cuellos de botella compartidos entre los flujos, entonces el algoritmo de control de la congestión en la mayoría de los casos aseguraran que la carga está distribuida uniformemente entre las sesiones TCP regulares y multicaminos para que ningún usuario final reciba un peor rendimiento que cuando recibe un único flujo TCP. Existen algunos casos extremos conocidos en que una actualización a MPTCP puede afectar a otros usuarios.

Además, la flexibilidad de MPTCP para agregar y remover sub flujos según cambios en los caminos disponibles podría conducir a variaciones del ancho de banda de conexión, las aplicaciones que se adaptan al ancho de banda disponible, como audio y video, pueden necesitar ajuste de sus parámetros para tener un mejor rendimiento.

El transporte de información de señalización MPTCP produce una baja sobre carga en la red. El uso de MPTCP en lugar de una sola conexión TCP resulta en un goodput [1] más pequeño, además si múltiples sub flujos comparten un mismo cuello de botella, esta sobre carga reduce ligeramente la capacidad disponible para el transporte de datos, sin embargo, esta potencial reducción de caudal será insignificante en muchos escenarios de uso, y el protocolo contiene optimizaciones en su diseño de modo que esta sobrecarga es mínima. V.3.

RETARDO

Los beneficios de MPTCP con respecto al troughput y a la capacidad de recuperación (Resilience) pueden llegar a algunos costos en relación con el retardo en la entrega de datos y retardos en el jitter. Si los retardos en los sub flujos que conforman una conexión MPTCP difieren, el Jitter perceptible para una aplicación puede parecer como superior a los datos que se transmiten a través de los subflujos. Aunque MPTCP asegurará el orden de entrega a la aplicación, los datos entregados pueden ser a ráfagas lo que es el caso más usual cuando se tiene una sola conexión TCP, en particular en conexiones altamente asimétricas.

23

MP-TCP

Las aplicaciones con alto requerimiento de tiempo real pueden verse afectadas por tal escenario, una solución es desactivar MPTCP para las aplicaciones más sensibles al jitter, ya sea mediante el uso de una API o por otros medios definidos en las políticas del sistema.

Sin embargo el retardo actual y el jitter en el trasporte de datos sobre MPTCP dependerá de los algoritmos de control de congestión usados para enviar los datos, así como la heurística para establecer y cerrar los sub flujos. Un emisor puede poner en práctica estrategias para reducir al mínimo el jitter visto por las aplicaciones, pero esto requiere una estimación precisa de las características del trayecto. Si las decisiones de planificación son suboptimas o si los supuestos sobre las características de los caminos resultan ser erróneos, el jitter puede aumentar y afectar aplicaciones sensibles a los retardos. En general, para una aplicación sensible al retardo es aconsejable seleccionar un algoritmo de control de congestión apropiado para sus necesidades de tráfico.

Alternativamente, MPTCP

podría ser utilizado para alta fidelidad en lugar de alto

troughput, operando en modos de traffic mirroring de sub flujos, o como hot standby creando un sub flujos adicionales. Estos métodos de scheduling de tráfico no causaría variación del retardo de la misma manera. Si uno de los sub flujos en el transporte de datos falla, las retransmisiones dentro de MPTCP podrían afectar el retardo de la aplicación. Sin embargo, sin MPTCP los datos o la conexión completa se hubieran perdido y otro mecanismo de fiabilidad, por ejemplo de recuperación en el nivel de aplicación, probablemente tendría un mayor impacto en el retardo. V.4. CAPACIDAD DE RECUPERARSE (RESILIENCE) Otra de las mejoras implementadas con el uso de MPTCP es una mejor capacidad de la red de recuperarse ante fallos o cortes en alguno de los enlaces. El uso de múltiples subflujos simultáneos significa que si uno falla, todo el tráfico se trasladará a los restantes subflujos y además cualquier paquete perdido se puede retransmitir por estos subflujos.

Como un caso especial MPTCP puede ser usado con un único subflujo activo en un tiempo dado, en este caso la capacidad de recuperación en comparación con el uso de una sola conexión TCP mejora. MPTCP también soporta hacer handover (traspasos) de flujos antes

MP-TCP

24

de las rupturas, así como romper antes de hacer traspasos entre sub flujos. En ambos casos la conexión MPTCP puede sobrevivir a una falta de disponibilidad o cambio de una dirección IP, por ejemplo debido a la caída de una interfaz. MPTCP cierra o reinicia la conexión MPTCP independientemente por subflujos individuales.

El fallo en un sub flujo puede ser causado por problemas dentro de la red que una aplicación podría desconocer, o por errores en una interfaz en un nodo.

VI.

CONSIDERACIONES DE SEGURIDAD

Como se ha expuesto en este trabajo MPTCP describe las extensiones propuestas al protocolo TCP para establecer que dos puntos finales de una conexión TCP determinada puedan utilizar varias rutas para el intercambio de datos. Dichas extensiones permiten el intercambio de segmentos utilizando diferentes pares de direcciones de origen-destino, que se traduce en el uso de diferentes caminos cuando se tienen diversos escenarios de conexión.

Aunque MPTCP es más seguro que el TCP normal, el soporte para múltiples direcciones IP por cada punto final puede tener implicaciones en la seguridad como resultado de implementar MPTCP. En este ítem vamos a tratar un tipo de amenaza que se puede generar al trabajar con múltiples direcciones IP en cada punto final.

Hay diferentes maneras de lograr múltiples rutas TCP en una conexión. Básicamente, se necesita que los distintos segmentos de la comunicación sean transmitidos a través de interfaces (caminos) diferentes, permitiendo al remitente que utilice algún algoritmo para escoger las diferentes trayectorias para el tráfico. Existen varias opciones para la escogencia de caminos, se pueden utilizar diferentes los siguientes saltos en una ruta, también se pueden emplear túneles a diferentes interfaces de salida.

En una comunicaciones TCP normal donde solo se tiene un camino para la conexión se puede realizar diferentes tipos de ataques, como son: Escaneos de puertos, Man in the Middle (MITM), SYN Flood, entre otros. Sin embargo no es posible que un atacante que no se encuentre en el mismo camino (en la red) puedan realizar estos ataques a un objetivo

25

MP-TCP

cualquiera. Hay un término medio cuando un atacante se encuentra en el camino por un corto periodo de tiempo para lanzar el ataque y luego se mueve, pero los efectos del ataque son aplicables. A continuación vamos a describir un tipo de ataque llamado Flooding que se puede lanzar en un ambiente con MPTCP

VI.1

ATAQUES TIPO FLOODING

En la siguiente figura se puede observar un escenario donde se emplea este tipo de ataques:

Figura 7. Escenario ataque de Flooding

El escenario consiste de un atacante (A) quien tiene una dirección IP (IP A). Un servidor que puede generar una cantidad suficiente de tráfico (Por ejemplo, un servidor de videostreaming) que llamaremos la fuente (S) que tiene una dirección IP configurada (IP S), el objetivo (T) también tiene una dirección IP configurada (IP T).

En el primer paso de este tipo de ataques, el atacante (A) establece una conexión MPTCP con la fuente del tráfico (Servidor S) y comienza a descargar una cantidad significante de paquetes. En la primera conexión solo se utiliza una dirección IP por cada extremo (IP A y IP S). Paso 2 una vez la descarga está en curso, el atacante (A) agrega la dirección IP T (del objetivo) como una de las direcciones habilitadas para la comunicación. Como se agrega esta dirección IP depende del tipo de gestión de direcciones que emplee MPTCP. En la gestión de direcciones explicita el atacante (A) solo necesita enviar un paquete de señalización con la dirección del objetivo (IP T), en el modo implícito el atacante necesitaría enviar un paquete con la dirección del objetivo como la dirección de origen. En esta etapa la conexión MPTCP todavía tiene una sola dirección IP para la fuente (S), pero

MP-TCP

26

hay 2 direcciones para el atacante (IP A y IP T). Ahora el atacante intenta conseguir la dirección intenta conseguir la dirección de la fuente para enviar el tráfico de la descargar en curso a la dirección de destino (IP del objetivo), el atacante puede hacer parecer que el camino entre A y T está congestionado pero que el camino entre S y T no lo está, para hacer eso necesita enviar ACKs por el flujo de datos entre IP S y IP T y no enviar ACKs por los datos que se envían a IP A. Los detalles de este proceso dependen de como los datos son enviados a través de diferentes caminos son negociados por medio de los ACKs, una posibilidad es que los ACKs para los datos enviados a través de un par de direcciones determinadas deben venir en un paquete que contiene el mismo par de direcciones, si es así el atacante tendría que enviar ACKs utilizando paquetes que contienen la dirección del objetivo como dirección de origen para mantener el flujo del ataque, esto puede o no ser posible, dependiendo de los filtros a la entrada y la ubicación del atacante. El atacante también debería adivinar el número de secuencia de los datos que están siendo enviados por el objetivo. Una vez el atacante se las arregla para realizar estas acciones el ataque tiene lugar y la descarga se realizara en el objetivo. En este tipo de ataque la fuente (S) estará pensando que está enviando paquetes al atacante mientras que en realidad los está enviando al objetivo (T).

VI.2.

ATAQUES TIPO SECUESTRO DE CONEXIÓN (HIJACKING)

El ataque de tipo secuestro de la comunicación básicamente usan el dinamismo en las direcciones IP en MPTCP para permitir a un atacante secuestrar una conexión, esto significa que la víctima de una conexión piensa que está hablando con un peer, pero por el contrario está intercambiando paquetes con el atacante. En cierto sentido este ataque es el dual del flooding, en donde la victima cree que está intercambiando paquetes con el atacante pero en realidad está enviando los paquetes hacia el objetivo. El escenario de un ataque de tipo secuestro se muestra a continuación:

27

MP-TCP

Figura 8. Escenario ataque de secuestro de conexion

Una conexión MPTCP está establecida entre el nodo 1 y el nodo 2, la conexión está usando una sola direccion para cada extremo (IP1 y IP2). El atacante lanza el ataque tipo secuestro agregando la direccion IP A como una direccion IP adicional para el nodo 1. No hay mucha diferencia entre la gestion implicita o explicita de direcciones, en ambos casos el atacante podria enviar facilmente enviar un paquete de control adicionando la direccion A ya sea como control de datos o como direccion origen del paquete de control. Para que sea posible el ataque, el atacante necesita conocer el par de direcciones y el par de puertos, si el atacante puede obtener estos datos podria ser capaz de participar en la comunicación y se podrian ver los siguientes casos: 1) Segmentos fluyen desde el nodo 1: En general, el objetivo principal de MPTCP es lograr trayectorias multiples, entonces se puede suponer que hay muchos pares de direcciones IP. Si el nodo 2 comenzara a enviar datos a la IP A significa que parte de los datos (pero no todos) alcanzarán al atacante, esto tiene consecuencias negativas ya que el nodo 1 no recibirá todos los datos del nodo 2, desde el punto de vista de una aplicación esto podria ser visto como un ataque de denegacion de servicio (DoS) ya que el flujo de datos se detendrá a la espera de los paquetes desaparecidos, sin embargo esto no suficiente para lograar el secuestro de la conexión completa ya que parte de los datos seran entregados al nodo 1. Para que el atacante reciba todos los datos debe de alguna manera eliminar la IP 1 del conjunto de direcciones disponibles para la conexión, esto será posbile en dependencia de la ubicación del atacante. 2) Segmentos fluyen desde el nodo 2: Tan pronto como la dirección IP A es aceptada por el nodo 2 como parte del set de direcciones disponibles para la conexión MPTCP, el

MP-TCP

28

atacante puede enviar paquetes usando la dirección IP A y estos paquetes serán considerados como parte de la conexión MPTCP por el nodo 2. Esto significa que el atacante será capaz de inyectar datos en la conexión MPTCP, desde esta perspectiva el atacante tiene secuestrado cierta parte del tráfico. Sin embargo, el nodo 1seguirá estando habilitado para enviar tráfico que será recibido por el nodo 2 como parte de la conexión MPTCP. VI.3. ATAQUE MAN IN THE MIDDLE (MITM)

Un ataque relacionado que se puede lograr usando técnicas similares sería el de Man in The Middle. El escenario para este tipo de ataque se puede observar en la siguiente figura:

Figura 9. Escenario ataque man in the middle

Hay una conexione establecida entre el nodo 1 y el nodo 2, el atacante A utilizará el dinamismo de direcciones MPTCP para colocarse como un “hombre en el medio (MiTM)”, para ello añade la direccion IP A como una direccion adicional para la conexión MPTCP, tanto para el nodo 1 como para el nodo 2. Esta tecnica es esencialmente la misma que la descrita en el item anterior, solo que en este caso se utiliza contra ambos nodos implicados en la comunicación. La principal diferencia es que en este caso el atacante puede simplemente esnifar el contenido de la comunicación que es transmitido a traves de él, y asu vez reenviará los datos a sus pares en la comunicación, esto puede pasar inadvertido para los nodos 1 y 2.

29

MP-TCP

VII.

CASOS DE USO E IMPLEMENTACIONES

El IP Networking Lab está implementado MPTCP en el kernel de Linux, los archivos los aloja en su sitio web para que los usuarios y desarrolladores puedan hacer pruebas y experimentar con el nuevo protocolo, el cual se encuentra en la versión estable V0.88 basada en el kernel de Linux v3.11. Los siguientes sitios web están utilizando la implementación de Linux MPTCP: http://multipath-tcp.org http://amiusingmptcp.com http://ixit.cz http://mapserver.flightgear.org http://scenemodels.flightgear.org http://technosrix.com http://watchy.in Para acceder a algunos de estos sitios debemos estar usando un Sistema operativo Linux que esté implementando MPTCP.

A continuación se muestra una figura de las conexiones, en las que se ha utilizado MPTCP, con el sitio web multipath-tcp.org, que se han hecho con MPTCP habilitado. Estas estadísticas fueron registradas desde 2012.

Figura 8. Mapa de origen de conexión a servidor con MPTCP

MP-TCP

30

Investigadores del IP Networking Lab hicieron una pequeña demostracion del uso de MPTCP sobre Ethernet/WiFi/3G con la implementacion que hicieron en el kernel de Linux.

Primero iniciaron una sesion SSH con un redireccionamiento X y lanzaron una aplicación denominada dem- screensaver en un servidor distante que tiene habilitado MPTCP. Cuando se desconecta el trafico Ethernet y WiFi gracias a MPTCP la conexión SSH es capaz de hacer traspaso sobre el trafico 3G sin que haya interrupcion de la experiencia del usuario. Si no se estuviera utilizando el kernel de linux con la implementacion de MPTCP la sesion SSH simplemente se hubiera detenido y hubiera sido necesario reiniciarla cuando las condiciones de la red mejoraran. Los investigadores en su pagina tienen publicado un video donde se muestra este proceso. En las referencias bibliograficas se se indica la URL a este video.



Conexión rapida con MPTCP

Con el gran crecimiento de informacion que se debe transportar por las redes, la transferencia rapida de datos es un objetivo clave para un gran numero de aplicaciones dentro de los centros de datos. Mientras que algunos centros de computo siguen utilizando conexiones Gigabit Ethernet (Gbps), muchos estan instalando interfacesc 10 Gigabit Ethernet (10 Gbps) en servidores de gama alta, el segundo paso seria 40 Gbps y 100 Gbps pero estas tecnologias no son del todo viables porque todavia son bastante costosas al dia de hoy.

Personal del la Universidad Catolica de Loouvaine (UCLouvain) hicieron una demostración para poner a prueba los límites de desempeño de MPTCP utilizando interfaces 10 Gbps, se empleó una configuración como la que se muestra a continuación:

31

MP-TCP

Figura 9. Escenario de laboratorio evaluacion capacidad con MPTCP

Se utilizaron 2 Servidores los cuales cada un tiene instaladas 3 interfaces de red 10 Gbps y los dos servidores funcionan bajo el sistema operativo Linux que tiene implementado MPTCP, que permite el uso de varias interfaces para un unico flujo de datos, por lo tanto aumenta la velocidad mediante la suma de ancho de banda de cada interfaz. Para lograr esto se necesita una configuracion especifica del kernel, optimizada para el hardware con el fin de aprovechar todos los recursos disponibles. Para medir la velocidad de transmision utilizaron netperf que es una herramienta estandar que permite comparar el rendimiento de TCP. Se tuvo que personalizar netperf para que soporte MPTCP. En las referencias bilbiograficas hay una URL de un video donde se muestra este experimento.



Conexión MPTCP en una red OpenFlow

Es una prueba que realizaron investigadores de SURFnet, en la cual se transmitiron datos entre 2 servidores, el escenario de prueba es una red Open Flow con el protocolo MPTCP en los dispositivos. En la figura se puede observar el escenario en que realizaron las pruebas

MP-TCP

32

Figura 10. Conexiones en experimento MPTCP sobre red OpenFlow

La topologia que se utilizó para realizar el experimento se muestra en la figura . En cada servidor hay instaladas 2 tarjetas de red 10 Gigabit Ethernet. El trafico fue distribuido por 2 rutas (colores verde y rojo del diagrama).

Figura 11. Topologia utilizada en experimento MPTCP sobre red OpenFlow

Se obtuvieron los siguientes resultados

33

MP-TCP

Figura 12. Resultados obtenidos en experimento MPTCP sobre red OpenFlow



Implementacion de MP-TCP en IOS 7 de Apple

A partir de la version 7 de IOS (Sistema operativo para dispositivos de la marca) se añadió soporte para MP-TCP en los equipos que lo tengan instalado. Con esto se pueden establecer conexiones via la red Celular 3G/4G y de la red WiFi al mismo tiempo somo se observa en la figura 13. Esto supondrá los beneficios que han sido descritos en el desarrollo de este trabajo.

Figura 13. Escenario posible con IOS 7

MP-TCP

VIII.

-

34

CONCLUSIONES

Las exigencias actuales requieren de la implementación de nuevos mecanismos para soportar el aumento del tráfico que fluye por la red sin tener la necesidad de instalar hardware costoso.

-

MPTCP es una solución que experimentalmente ha dado excelentes resultados puesto que al aumentar la cantidad de subflujos de un mismo tráfico, el ancho de banda disponible aumenta considerablemente.

-

Además, se garantiza que siempre haya un flujo TCP en la conexión (si queda al menos un camino), lo cual garantizará un camino para enviar la información haciendo mucho más robusta la red y con la capacidad de recuperarse ante fallos o congestión en algunos de sus caminos. Esto supone gran interés para las comunicaciones donde se tiene gran dinamismo en el establecimiento y ruptura de las conexiones como las redes Ad-Hoc o las redes MANET.

-

Es importante que se tenga en cuenta el tema de la seguridad cuando se trabaja con el nuevo protocolo, puesto que se pueden generar brechas de seguridad al ser dinámico el intercambio de información en el establecimiento de conexiones entre un cliente y un servidor.

-

Se necesita que haya más Sistemas Operativos que habiliten de manera nativa MP-TCP para hacer un uso más general del mismo, puesto que hasta el momento no se encontró información que otro sistema lo soporte, solo Linux lo ha implementado en su kernel.

35

MP-TCP

IX.

REFERENCIAS Y BIBLIOGRAFÍA

[1] Ronald van der Pol, Michael Bredel, Artur Barczyk, Benno Overeinder, Niels van Adrichem, Fernando Kuipers. “Experiences with MPTCP in an intercontinental OpenFlow network”. [2] Sébastien Barré, Christoph Paasch, and Olivier Bonaventure. “MultiPath TCP: From Theory to Practice” [3] Costin Raiciu, Christoph Paasch, Sebastien Barre, Alan Ford, Michio Honda, Fabien Duchene, Olivier Bonaventure and Mark Handley. “How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP” [4] Ronald van der Pol, Michael Bredel, Artur Barczyk, Benno Overeinder, Niels van Adrichem, Fernando Kuipers. “Experiences with MPTCP in an intercontinental OpenFlow network” [5] Internet Engineering Task Force. Architectural Guidelines for Multipath TCP Development. RFC 6182 [6] Internet Engineering Task Force. Multipath TCP Application Interface Considerations. RFC 6897. [7] Internet Engineering Task Force. Threat Analysis for TCP Extensions for Multipath Operation. RFC 6181. [8] http://www.multipath-tcp.org/ Página web del proyecto implementación MPTCP en Linux [9] http://www.cisco.com/en/US/tech/tk364/technologies_tech_note09186a00 [10] http://www.networkworld.com/news/2013/091913-ios7-multipath-273995.html [11] http://www.youtube.com/watch?v=VWN0ctPi5cw/ Página video resultado experimentos [12] http://www.youtube.com/watch?v=VMdPI9Cfi9k/ Página video resultado experimentos