You are on page 1of 35

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. III.3. III.4. III.5. III.6. III.7. III.8. DECISIÓN DE DISEÑO DE ALTO NIVEL BUFFER SEÑALIZACIÓN MANEJO DE CAMINO IDENTIFICACIÓN DE CONEXIÓN CONTROL DE LA CONGESTION 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. V.4. RETARDO CAPACIDAD DE RECUPERACION DE LA RED (RESILIENCE)

VI. CONSIDERACIONES DE SEGURIDAD VI.1. VI.2. VI.3. VII. ATAQUES TIPO FLOODING ATAQUES TIPO SECUESTRO DE CONEXIÓN (HIJACKING) ATAQUE MAN IN THE MIDDLE (MITM)

CASOS DE USO E IMPLEMENTACIONES

VIII. CONCLUSIONES IX. REFERENCIAS Y BIBLIOGRAFÍA

ancho de banda) no pueden ser completamente utilizados debido a las restricciones del protocolo en los sistemas finales dentro de la red. . Describir las aplicaciones actuales. donde uno o ambos de los usuarios finales tienen múltiples tarjetas. e incrementar la capacidad de la red disponible para los usuarios finales. Describir la arquitectura en la que se basa el funcionamiento de MP-TCP. protegiendo usuarios finales de la falla de uno. Los dos principales beneficios de transporte multipath son los siguientes:   Incrementar la resistencia de la conectividad proveída por los múltiples caminos. pero frecuentemente estos recursos (en especial. Estas mejoras también reducirían la necesidad de gastos en infraestructura de la red. Esto puede tener aplicaciones también donde los caminos múltiples existen dentro de una red y pueden ser manipulados por un usuario final. INTRODUCCIÓN Con la evolución del Internet. I. transparentemente para la aplicación. 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.MP-TCP 4 OBJETIVOS - Conocer el funcionamiento del protocolo MP-TCP. la demanda de los recursos incrementa. 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. Hacer una comparación con TCP actual y resaltar ventajas y desventajas. Si estos recursos se los podría usar correctamente. Incrementar la eficiencia del uso de recursos. como usando diferente número de puertos con Equal Cost MultiPath (ECMP). la experiencia del usuario final podría ser enormemente mejorada. MP-TCP tiene como preocupación principal el uso múltiple de caminos extremo a extremo.

Dos hosts. A1-B2. A2-B2. El diagrama presentado en la figura 1. A2-B1. Los caminos creados por esta combinación de direcciones a través de Internet no necesitan ser enteramente disjunto. metas para las que MP-TCP fue diseñado. proveyendo dos conexiones disjuntas a internet.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. están comunicándose entre ellos. ESCENARIO DE REFERENCIA. ilustra el escenario de uso típico para MPTCP. (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. 1 y B2. Mejorar el Throughput: MP-TCP debe soportar el uso concurrente de múltiples caminos. II. 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. Para lograr los incentivos mínimos de desempeño para el despliegue. II. 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.1. Las direcciones de cada hosts están referidas a A1. . tantas como caminos disponibles entre hosts se quieran. A continuación se pretende describir como objetivos: (i) Describir metas para un transporte multipath. Estos hosts tienen multi-tarjeta y múltiples direcciones. A y B.  METAS FUNCIONALES. A2. Por lo que hay 4 caminos diferentes entre 2 hosts: A1-B1.

Además de cumplir con las metas funcionales MP-TCP debe cumplir con las siguientes categorías de metas de compatibilidad.MP-TCP 6  Mejorar Resistencia: MT-TCP debe soportar el uso de múltiples caminos intercambiables para propósitos de resistencia. sin embargo. permitiendo que los segmentos se envíen y reenvíen por cualquier camino disponible. en orden. confiable. II. Además. cambiando la carga lejos de cuellos de botella congestionados y tomando ventaja de la posibilidad de esparcir la capacidad donde sea. puede ser capaz de proveer el mismo nivel de consistencia del troughput y latencia que una conexión TCP simple. 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. METAS DE COMPATIBILIDAD.  Compatibilidad de Aplicación. 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. MP-TCP debe seguir el mismo modelo de servicio que TCP. usándolas si puede y caso contrario automáticamente regresa a la conexión TCP 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. Además. MP-TCP debe tener la característica de negociación automática de su uso. 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. entrega orientada a byte. Así en el peor de los casos. MP-TCP no debe. 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. . el protocolo debe ser resistente no menos que un TCP regular de camino único.2.

las metas de seguridad de MP-TCP es proveer un servicio no menos seguro que el regular TCP. la arquitectura debe permitir nuevos flujos MP-TCP para coexistir con los flujos TCP de camino único existentes. III. Y de la protección contra las nuevas amenazas multipath identificadas. MP-TCP debe trabajar con IPv4 y IPv6. más allá del impacto que ocurriría de otro flujo TCP simple. Requiere que la extensión multipath para retener la compatibilidad TCP con el Internet existe hoy. II. como firewalls. MP-TCP debe preservar fate-sharing sin hacer suposiciones acerca del comportamiento de la caja intermedia. que se analizan posteriormente. MP-TCP debe retroceder a TCP regular si existen incompatibilidades insuperables para la extensión multipath en el camino. El uso de caminos múltiples no debe afectar a los usuarios que usan TCP simple en cuellos de botella compartidos. Flujos MP-TCP en cuellos de botella compartidos debe compartir el ancho de banda entre cada uno de forma equitativa. El nuevo modelo de Internet descrito se basa en ideas propuestas en Tng (“Transport nextgeneration”).7 MP-TCP  Compatibilidad de la Red. incluyendo hacer esfuerzos razonables para ser capaz de atravesar cajas intermedias predominantes. por esto. Las modificaciones para soportar MP-TCP permanece en la capa de transporte. ARQUITECTURA BÁSICA PARA MP-TCP. METAS DE SEGURIDAD. La extensión de TCP con capacidades mutipath traerá un número de nuevas amenazas. Esto se logrará a través de la combinación de mecanismos de seguridad TCP existentes. NATs y proxies para mejorar el rendimiento. compitiendo por el ancho de banda no muy agresivamente ni débilmente. Como corolario para ambas compatibilidades.3. .

el cual provee compatibilidad de la red por aparición y comportamiento como flujo TCP en la red.1. 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. 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. DESCOMPOSICIÓN FUNCIONAL DE MP-TCP. III. 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. El diseño de arquitectura MP-TCP sigue la descomposición de las Tng. como término “subflujo” para proveer de transporte subyacente por camino. MP-TCP hace uso de sesiones estándar TCP “aparenta que está en la red”. y así mantiene la .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”. es una instanciación de la capa Flow+Endpoint “orientada a la red”. es una instanciación de la capa semántica “orientada a la aplicación”. Como extensión del protocolo TCP. como muestra la figura 2. 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. mientras el subflujo del componente TCP. MP-TCP. mientras que tradicionalmente se encuentra en la ostensible capa de transporte “extremo a extremo”.

El programador de paquetes es dependiente de información acerca de disponibilidad de caminos expuestos por el componente de manejo de caminos. y mecanismos para la creación de nuevos subflujos unidos a una conexión existente MPTCP. Para lograr esto debe implementar las siguientes funciones:  Manejo de camino: función para detectar y usar los múltiples caminos entre dos hosts. El diseño MP-TCP hace uso de paso de secuencia de datos.  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. 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. permitiendo a los segmentos enviados en diferentes subflujos ser correctamente reordenados en el receptor.9 MP-TCP compatibilidad de la red deseada. MP-TCP usa la presencia de múltiples direcciones IP en uno o ambos de los hosts como un indicador de esta. y luego hace uso de los subflujos para transmitir segmentos encolados. La información MP-TCP específica es llevada en forma compatible TCP. En la figura se puede ilustrar la arquitectura en capas. asociando segmentos enviados en diferentes subflujos para la numeración de la secuencia del nivel de conexión. Las características del manejo de caminos del protocolo MP-TCP son los mecanismos para dirección de señal alternativa para hosts. Figura 3. este mecanismo es separado de la información actual que es transferida que podría evolucionar en revisiones futuras. Esta función es también responsable para el reordenamiento del nivel de .

TCP asegura la entrega en orden y confiable. El subflujo recibido reordena los datos (si es necesario) y los pasa al componente programador de componentes. acorde al mapeo de secuencia de datos adjunto. el componente de control de la congestión existe como parte del programador de paquetes. . TCP añade sus propios números de secuencia a los segmentos. que realiza el reordenamiento a nivel de la conexión y envía el stream de datos a la aplicación.  Control de Congestión: Esta función coordina el control de la congestión a través de subflujos. MP-TCP usa TCP por debajo de la compatibilidad de la red. Estas funciones deben juntárselas de la siguiente manera. y se encarga de las operaciones necesarias en este (como segmentación de datos en segmentos de nivel de conexión. inicialización) de múltiples caminos entre dos hosts. 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. 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.MP-TCP 10 conexión en la recepción de paquetes de los subflujos TCP. el subflujo pasa sus datos reensamblados al componente de programación de paquetes para reensamblar a nivel de conexión. asegurando la entrega detectable para el host. para programar cual segmento deberá enviarse a que tasa y con cual subflujo. el mapeo de secuencia de datos desde el componente de programación de paquetes del emisor permite el reordenamiento del byte stream entero. ACK’s y los pasa a la red. El programador de paquetes luego recibe el stream de datos desde la aplicación destinada por la red. estos suelen detectar y retransmitir pérdida de paquetes en la capa de subflujo. El administrador de caminos busca después del descubrimiento (y si es necesario. Finalmente. En recepción.  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.

Este mapeo puede ser representado como una tupla de (número de secuencia de datos. para entregarlos a la aplicación. tamaño). Esto tiene dos problemas: primero el subflujo individual aparecerá para la red como sesión TCP con lagunas en los espacios de secuencia. 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. El emisor debe ser capaz de decir al receptor como reesnamblar los datos. Si una señalada (número de secuencia de datos. se menciona la siguiente línea de diseño de alto nivel que se basa en la arquitectura básica. e iría en contra de la meta de compatibilidad de la red. o ciertos proxies transparentes. con el cual se envía en múltiples subflujos.11 MP-TCP III. número de secuencia de subflujo tamaño). por instancia. Aparentemente hay un amplio rango de decisiones cuando estas diseñando una extensión multipath de TCP. 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. 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. para las cajas intermedias que re segmenta o ensambla datos. La aproximación alternativa usaría un número de secuencia de nivel de conexión simple. como una opción TCP.2. tamaño) y añadir solamente el número de secuencia de datos en cada segmento. 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. Esto es referido a “mapeo de secuencia de datos”.  Secuencia de numeración. sin embargo. DECISIÓN DE DISEÑO DE ALTO NIVEL. Esto sería vulnerable. Sin embargo. no hay comportamiento específico para incorporar opciones TCP. esta seguirá siendo vulnerable para cajas . 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. Segundo. esto puede molestar algunas cajas intermedias como lo son los sistemas de detección de intrusos.

Esto significaría que una vez el segmento es reconocido en el nivel de subflujo. Esto también podría ser excluido enteramente en el caso de una conexión anterior más que un subflujo utilizado. .  Retransmisiones y Fiabilidad. es posible concebir para que en algunos casos donde el reconocimiento de nivel de conexión pueda mejorar la robustez.MP-TCP 12 intermedias que incorporan segmentos y no entienden señalización MP-TCP así que no coescribirá las opciones correctamente. sec. Además. Segundo. y esto puede ser facilitado por un reconocimiento a niel de conexión. donde el espacio de secuencia de nivel de datos y nivel de subflujo es el mismo. los tres pedazos de datos (sec. de subflujo y tamaño) deben enviarse. Bajo ciertas circunstancias. La transmisión de ACKs TCP para un subflujo son manejadas enteramente al nivel de retransmisión de nivel de subflujo. 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. no podrá ser descartado en el buffer de re-orden en el nivel de conexión. 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. diferente al estándar TCP. Bajo comportamiento normal. Para reducir el encabezado. Esto tiene cierta implicación en semánticas extremo a extremo. debido a la presión de memoria. están para proveer servicio de robustez a la aplicación. puede ser deseable para desechar segmentos después de reconocerlos en el subflujo pero antes de entregarlos a la aplicación. un receptor no puede simplemente desechar segmentos fuera de orden si necesita (por ejemplo. de datos. 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. Las características de reconocimiento MP-TCP en el nivel de conexión como en el nivel de subflujo. podría ser permisible para el mapeo para ser enviado periódicamente y cubierto más que en un segmento simple.

además esto puede ser deseable en ciertos casos. para reducir los requerimientos de buffer de recepción. y usa el primer timeout como indicador. La programación de retransmisiones tendrá impacto significante en la experiencia de los usuarios MPTCP. para proveer una solución TCP multipath completamente robusta. III. los segmentos perdidos deben todavía ser enviados en el camino que se perdieron. se pierde un poco de eficiencia. Si se hace esto. a MP-TCP para uso en Internet público debe tener la característica de reconocimiento explícito de nivel de conexión. Típicamente. Esto se cree necesario para mantener la integridad del subflujo. Sin embargo. BUFFERS. 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. adicionalmente para reconocimientos de nivel de subflujo. estas deben ser posibles para un segmento para ser retransmitida en diferentes subflujos desde el que fue originalmente enviado. 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. MP-TCP debe usar un buffer de recepción al nivel de conexión. Para asegurar la entrega en orden. . el receptor debe tener suficiente buffering para almacenar todos los datos hasta que el segmento perdido sea retransmitido y alcance el destino. En MP-TCP. donde los segmentos son colocados hasta que son ordenados y pueden ser leídos por la aplicación. Versiones más conservadoras sería usar un segundo o tercer timeout para el mismo segmento. por ejemplo. en todos los casos con retransmisiones en diferentes subflujos.3. En cuanto a retransmisiones.13 MP-TCP Por lo tanto. rápida retransmisión en un subflujo individual no disparará retransmisiones en otro subflujo. El reconocimiento de nivel de conexión sería solamente requerido por la señal cuando reciba una ventana de avanzar.

Si el búfer de envío requerido es muy largo. un host puede escoger solamente enviar datos en los subflujos rápidos. . 2*sum(BW_i)*RTT_max. Uno requerimiento más sensible es para evitar estancarse en ausencia de timeouts. Esto es un orden de magnitud más que el búfer de recepción requerido para una conexión simple. El tamaño del búfer resultante debe ser lo pequeño suficiente para uso práctico. Este tamaño de buffer asegura que los subflujos no se estanquen cuando hay retransmisiones rápidas disparadas en cualquier subflujo. en este caso. Esto es porque el emisor debe almacenar localmente los segmentos enviados pero no reconocidos por el nivel de conexión ACK. 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.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. Donde. El tamaño del búfer de envío importa particularmente para hosts que mantienen un largo número de conexiones en marcha. De ahí lo recomendado es que el búfer de recepción sea. RTT_max es el RTT más largo a lo largo de todos los subflujos. el receptor tiene que poner la data de todos los subflujos en el buffer por la duración del RTO. Buffer del envío: el recomendado es el mismo tamaño que el recomendado para recepción. BW_i = ancho de banda para cada subflujo RTO_max es el RTO más largo a lo largo de todos los subflujos. Donde. y es probablemente también costosa para propósitos prácticos. usando el subflujo lento solamente en caso de falla.

el cual puede permitir la extensión de MP-TCP para usar puertos como direcciones para seleccionar el camino. Se espera que estos caminos. esto debe señalar al peer que soporta MP-TCP y desea usar esa conexión. Sin embargo. sería factible reemplazar el . El uso de múltiples direcciones IP es un simpe mecanismo que no requiere características adicionales en la red. no sean necesarios mientras no se sobrepongan. permitiendo que sea creado y procesado por separado del data stream. MANEJO DE CAMINOS Actualmente. con estos mecanismos. MP-TCP usa múltiples direcciones en uno o dos hosts para inferir diferentes caminos a lo largo de la red. Múltiples diferentes pares de direcciones (origen.5. la red no expone diversidad de caminos entre pares de direcciones IP. SEÑALIZACIÓN Como MP-TCP usa TCP. III.4. El protocolo MP-TCP diseñado usaría opciones TCP para esta señalización adicional. Además se requiere señalización durante la operación de la sesión MPTCP. 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. Esto permitirá a los hosts usar balanceo de carga basado en puerto con MPTCP. sus mecanismos de transporte de subflujos. serían suficientemente disjuntos para permitir multipath para lograr mejorar el throughput y robustez. la señalización requerida para operar MP-TCP es transportado separadamente de los datos. y el host debe ser capaz de añadir nuevos subflujos para conexiones MP-TCP. Sin embargo. en el caso típico. en conexiones MPTCP también inician como una conexión TCP simple. y para información del otro host acerca de otra dirección IP disponible. interfaz de subflujo y funciones de control de congestión de MP-TCP. destino) serían usados como caminos selectores en la mayoría de los casos. Para alcanzar diversidad de caminos en las redes IP de hoy. como para reensamblar a lo largo de múltiples subflujos. y reteniendo la compatibilidad de arquitecturas con entidades de la red. Para aumentar la oportunidad de éxito se configuran subflujos adicionales.15 MP-TCP III. cada camino será identificado por un estándar five-tuple.

Figura 4. el cual es único localmente dentro del host.6. dirección y puerto destino. número de protocolo) para la entereza de su existencia.Servidor III. donde las aplicaciones toman decisiones deliberadas del camino en uso. MP-TCP no debe ser usado para aplicaciones que requieren unirse a una interfaz o dirección específica. cada dispositivo con dos interfaces de red diferentes. 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. La conexión MP-TCP será identificada por los 5-tuple del primer subflujo TCP. Caminos Disponibles Conexión Cliente . IDENTIFICACIÓN DE CONEXIÓN. . Se observan los caminos posibles para una conexión entre un cliente y un servidor.MP-TCP 16 diseño basado en direcciones IP con un mecanismo de selección alternativa de caminos. Cada conexión MP-TCP requiere un identificador de conexión en cada host. sin cambios significativos en los otros componentes funcionales. Como una conexión MP-TCP no se limita al tradicional 5-tuple (dirección y puerto origen. En la figura 4.

Proveer la verificación que los peer pueden recibir tráfico en la nueva dirección antes de añadirla. entonces se perderá 4 veces los flujos. Un MP-TCP multi-direccionado debe ser capaz de hacer lo siguiente: a. es decir. los algoritmos de control de la congestión en cada subflujo deben estar acoplados en alguna manera. si se ejecuta simplemente un mecanismo para evitar congestión en cada ruta independiente. El control de la congestión en un ambiente MPTCP debe ser diseñado para lograr una asignación equitativa de los recursos. SEGURIDAD. 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. si un flujo mulipath tiene 4 caminos disponibles y todos ellos tienen que pasar por el mismo cuello de botella. por ejemplo. 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.8. y balance de la congestión alejando tráfico de los caminos más congestionados. el resultado global con muchos trayectos es que la tasa de perdida de una red tiende a equilibrarse. . de acuerdo a las trayectorias o rutas que tenga disponible. trasladar el tráfico en caminos que eviten puntos de congestión. Se identifican tres requerimientos de seguridad. Para lograr estas metas.17 MP-TCP III. b. 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. Esto es una forma de balanceo de carga. 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á. Hay tres metas que los algoritmos de control de la congestión usados en la implementación MPTCP: mejorar el throughput. III.7. no afectar a otros usuarios de la red.

también proporciona mecanismos para distinguir entre diferentes servicios o aplicaciones dentro de una misma maquina a través de los puertos. Proveer protección contra la reproducción. TCP es un protocolo de nivel de transporte. y permanece sin estado hasta alcanzar el estado ESTABLISHED. 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 . Mecanismos adicionales han sido desplegados como parte de la pila estándar TCP para proveer resistencia para ataques de Denial-ofXervice (DoS). 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.MP-TCP 18 c. Por ejemplo. hay varios mecanismos para proteger contra ataques de reseteo TCP. COMPARACION CON TCP ESTANDAR. MP-TCP debe. continuar proveyendo la funcionalidad y como mínimo evitar la carga computacional significativa antes de alcanzar el estado ESTABLISHED. IV. es decir. Esto debe ser notado: a) El uso de opciones TCP significativamente limitan la cantidad de información que puede ser llevada en el handshake. c) El deseo de portar un “break-before-make”. 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). b) La necesidad para trabajar a través de cajas intermedias resulta en la necesidad de manejar la mutabilidad de paquetes. idealmente. y TCP Multipath debe continuar para soportar una protección similar. es un protocolo orientado a la conexión. 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.

los componentes TCP reciben los datos de una aplicación (La aplicación no necesita ser modificada).19 MP-TCP Figura 5. En la figura 6. estos mecanismos garantizan que si hay congestión en alguna ruta. Se aprecia el proceso para realizar una conexión utilizando MPTCP . entonces MPTCP divide los datos en múltiples segmentos que se convertirán en subflujos TCP. Establecimiento conexión TCP En un kernel que tenga habilitado MPTCP. Se hace balanceo de carga 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. el tráfico sea desviado por otro camino que presente menor congestión. los componentes TCP se reemplazarán por componentes MPTCP y subflujos TCP para cada interfaz. Cada uno de estos subflujos se comporta como una conexión TCP normal en la red.

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.MP-TCP 20 Figura 6.  Implementa control de congestión. Estos segmentos estarán numerados para que al recibirlos se puedan ordenar correctamente y reconstruir los datos originales. 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 . 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.

A continuación se detalla los efectos en el rendimiento con MPTCP desde el punto de vista de una aplicación: V. 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.21 MP-TCP Figura 7.1. MEJORA EN TROUGHPUT La mejora en el rendimiento más obvia que se puede esperar al implementar MPTCP es un aumento en el troughput. que se traduce en una mejor calidad de experiencia de los usuarios. ya que MPTCP agrupará más de un camino (cuando sea posible) . MEJORAS INTRODUCIDAS CON MPTCP V. Capas superiores modelo TCP/IP La utilización del nuevo protocolo supondrá ua serie de mejoras a las prestaciones de la red.2. En el siguiente apartado se hará una breve descripción de estos beneficios. 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. V.

sin embargo.MP-TCP 22 entre dos puntos finales. El uso de MPTCP en lugar de una sola conexión TCP resulta en un goodput [1] más pequeño. las aplicaciones que se adaptan al ancho de banda disponible. además si múltiples sub flujos comparten un mismo cuello de botella. si se pone en marcha un sub flujo en un periodo corto de tiempo. Esto usualmente provee un ancho de banda más grande para una aplicación. Existen algunos casos extremos conocidos en que una actualización a MPTCP puede afectar a otros usuarios. V. 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. Si los retardos en los sub flujos que conforman una conexión MPTCP difieren. . como audio y video. los datos entregados pueden ser a ráfagas lo que es el caso más usual cuando se tiene una sola conexión TCP. Si hay cuellos de botella compartidos entre los flujos. pueden necesitar ajuste de sus parámetros para tener un mejor rendimiento. Aunque MPTCP asegurará el orden de entrega a la aplicación. Además. en particular en conexiones altamente asimétricas.3. esta potencial reducción de caudal será insignificante en muchos escenarios de uso. el troughput puede ser menor que el óptimo teórico. aunque pueden existir excepciones debido al control dinámico de la congestión. Por ejemplo. y el protocolo contiene optimizaciones en su diseño de modo que esta sobrecarga es mínima. El transporte de información de señalización MPTCP produce una baja sobre carga en la red. esta sobre carga reduce ligeramente la capacidad disponible para el transporte de datos. 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. 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. el Jitter perceptible para una aplicación puede parecer como superior a los datos que se transmiten a través de los subflujos.

así como la heurística para establecer y cerrar los sub flujos. Alternativamente. Si las decisiones de planificación son suboptimas o si los supuestos sobre las características de los caminos resultan ser erróneos. las retransmisiones dentro de MPTCP podrían afectar el retardo de la aplicación. Sin embargo. todo el tráfico se trasladará a los restantes subflujos y además cualquier paquete perdido se puede retransmitir por estos subflujos. En general. MPTCP también soporta hacer handover (traspasos) de flujos antes . el jitter puede aumentar y afectar aplicaciones sensibles a los retardos. una solución es desactivar MPTCP para las aplicaciones más sensibles al jitter. operando en modos de traffic mirroring de sub flujos. o como hot standby creando un sub flujos adicionales. probablemente tendría un mayor impacto en el retardo.4.23 MP-TCP Las aplicaciones con alto requerimiento de tiempo real pueden verse afectadas por tal escenario. 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. 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. ya sea mediante el uso de una API o por otros medios definidos en las políticas del sistema. para una aplicación sensible al retardo es aconsejable seleccionar un algoritmo de control de congestión apropiado para sus necesidades de tráfico. 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 uno de los sub flujos en el transporte de datos falla. El uso de múltiples subflujos simultáneos significa que si uno falla. 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. MPTCP podría ser utilizado para alta fidelidad en lugar de alto troughput. V. Estos métodos de scheduling de tráfico no causaría variación del retardo de la misma manera. 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.

En ambos casos la conexión MPTCP puede sobrevivir a una falta de disponibilidad o cambio de una dirección IP. que se traduce en el uso de diferentes caminos cuando se tienen diversos escenarios de conexión. o por errores en una interfaz en un nodo. también se pueden emplear túneles a diferentes interfaces de salida. entre otros. Básicamente. Aunque MPTCP es más seguro que el TCP normal. como son: Escaneos de puertos. Existen varias opciones para la escogencia de caminos. 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. MPTCP cierra o reinicia la conexión MPTCP independientemente por subflujos individuales. se necesita que los distintos segmentos de la comunicación sean transmitidos a través de interfaces (caminos) diferentes. 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 . así como romper antes de hacer traspasos entre sub flujos. El fallo en un sub flujo puede ser causado por problemas dentro de la red que una aplicación podría desconocer. se pueden utilizar diferentes los siguientes saltos en una ruta. SYN Flood. permitiendo al remitente que utilice algún algoritmo para escoger las diferentes trayectorias para el tráfico. Dichas extensiones permiten el intercambio de segmentos utilizando diferentes pares de direcciones de origen-destino.MP-TCP 24 de las rupturas. Man in the Middle (MITM). 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. VI. En una comunicaciones TCP normal donde solo se tiene un camino para la conexión se puede realizar diferentes tipos de ataques. por ejemplo debido a la caída de una interfaz. Hay diferentes maneras de lograr múltiples rutas TCP en una conexión. el soporte para múltiples direcciones IP por cada punto final puede tener implicaciones en la seguridad como resultado de implementar MPTCP.

En el primer paso de este tipo de ataques. Como se agrega esta dirección IP depende del tipo de gestión de direcciones que emplee MPTCP. En esta etapa la conexión MPTCP todavía tiene una sola dirección IP para la fuente (S). pero los efectos del ataque son aplicables. un servidor de videostreaming) que llamaremos la fuente (S) que tiene una dirección IP configurada (IP S). 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). A continuación vamos a describir un tipo de ataque llamado Flooding que se puede lanzar en un ambiente con MPTCP VI. 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.25 MP-TCP cualquiera. 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.1 ATAQUES TIPO FLOODING En la siguiente figura se puede observar un escenario donde se emplea este tipo de ataques: Figura 7. en el modo implícito el atacante necesitaría enviar un paquete con la dirección del objetivo como la dirección de origen. pero . En la primera conexión solo se utiliza una dirección IP por cada extremo (IP A y IP S). el objetivo (T) también tiene una dirección IP configurada (IP T). el atacante (A) agrega la dirección IP T (del objetivo) como una de las direcciones habilitadas para la comunicación. 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. Paso 2 una vez la descarga está en curso.

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. Una vez el atacante se las arregla para realizar estas acciones el ataque tiene lugar y la descarga se realizara en el objetivo. 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. dependiendo de los filtros a la entrada y la ubicación del atacante.MP-TCP 26 hay 2 direcciones para el atacante (IP A y IP T).2. En cierto sentido este ataque es el dual del flooding. 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). pero por el contrario está intercambiando paquetes con el atacante. 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á. esto significa que la víctima de una conexión piensa que está hablando con un peer. 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. en donde la victima cree que está intercambiando paquetes con el atacante pero en realidad está enviando los paquetes hacia el objetivo. 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. El escenario de un ataque de tipo secuestro se muestra a continuación: . esto puede o no ser posible. VI. 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 también debería adivinar el número de secuencia de los datos que están siendo enviados por el objetivo.

Para que sea posible el ataque.27 MP-TCP Figura 8. 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. esto será posbile en dependencia de la ubicación del atacante. 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. No hay mucha diferencia entre la gestion implicita o explicita de direcciones. 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. 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. El atacante lanza el ataque tipo secuestro agregando la direccion IP A como una direccion IP adicional para el nodo 1. el objetivo principal de MPTCP es lograr trayectorias multiples. la conexión está usando una sola direccion para cada extremo (IP1 y IP2). 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. el . Escenario ataque de secuestro de conexion Una conexión MPTCP está establecida entre el nodo 1 y el nodo 2. esto tiene consecuencias negativas ya que el nodo 1 no recibirá todos los datos del nodo 2. 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 atacante necesita conocer el par de direcciones y el par de puertos. entonces se puede suponer que hay muchos pares de direcciones IP. 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.

. 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. el atacante A utilizará el dinamismo de direcciones MPTCP para colocarse como un “hombre en el medio (MiTM)”.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. Esta tecnica es esencialmente la misma que la descrita en el item anterior. desde esta perspectiva el atacante tiene secuestrado cierta parte del tráfico. para ello añade la direccion IP A como una direccion adicional para la conexión MPTCP.3. esto puede pasar inadvertido para los nodos 1 y 2. tanto para el nodo 1 como para el nodo 2. solo que en este caso se utiliza contra ambos nodos implicados en la comunicación. Escenario ataque man in the middle Hay una conexione establecida entre el nodo 1 y el nodo 2. el nodo 1seguirá estando habilitado para enviar tráfico que será recibido por el nodo 2 como parte de la conexión MPTCP. Sin embargo. El escenario para este tipo de ataque se puede observar en la siguiente figura: Figura 9. y asu vez reenviará los datos a sus pares en la comunicación. 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. Esto significa que el atacante será capaz de inyectar datos en la conexión MPTCP. VI.

CASOS DE USO E IMPLEMENTACIONES El IP Networking Lab está implementado MPTCP en el kernel de Linux. en las que se ha utilizado MPTCP.11.flightgear. A continuación se muestra una figura de las conexiones. Figura 8. Los siguientes sitios web están utilizando la implementación de Linux MPTCP: http://multipath-tcp.88 basada en el kernel de Linux v3. que se han hecho con MPTCP habilitado.cz http://mapserver.org http://scenemodels.com http://watchy.com http://ixit.flightgear. el cual se encuentra en la versión estable V0.29 MP-TCP VII. Estas estadísticas fueron registradas desde 2012.org.org http://technosrix.org http://amiusingmptcp.in Para acceder a algunos de estos sitios debemos estar usando un Sistema operativo Linux que esté implementando MPTCP. con el sitio web multipath-tcp. los archivos los aloja en su sitio web para que los usuarios y desarrolladores puedan hacer pruebas y experimentar con el nuevo protocolo. Mapa de origen de conexión a servidor con MPTCP .

muchos estan instalando interfacesc 10 Gigabit Ethernet (10 Gbps) en servidores de gama alta. 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. 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.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. 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. se empleó una configuración como la que se muestra a continuación: . la transferencia rapida de datos es un objetivo clave para un gran numero de aplicaciones dentro de los centros de datos. Primero iniciaron una sesion SSH con un redireccionamiento X y lanzaron una aplicación denominada dem.  Conexión rapida con MPTCP Con el gran crecimiento de informacion que se debe transportar por las redes. 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.screensaver en un servidor distante que tiene habilitado MPTCP. Mientras que algunos centros de computo siguen utilizando conexiones Gigabit Ethernet (Gbps). 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.

que permite el uso de varias interfaces para un unico flujo de datos. en la cual se transmitiron datos entre 2 servidores.31 MP-TCP Figura 9. Para lograr esto se necesita una configuracion especifica del kernel. por lo tanto aumenta la velocidad mediante la suma de ancho de banda de cada interfaz. 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.  Conexión MPTCP en una red OpenFlow Es una prueba que realizaron investigadores de SURFnet. Se tuvo que personalizar netperf para que soporte MPTCP. En las referencias bilbiograficas hay una URL de un video donde se muestra este experimento. En la figura se puede observar el escenario en que realizaron las pruebas . el escenario de prueba es una red Open Flow con el protocolo MPTCP en los dispositivos. Para medir la velocidad de transmision utilizaron netperf que es una herramienta estandar que permite comparar el rendimiento de TCP. optimizada para el hardware con el fin de aprovechar todos los recursos disponibles.

Conexiones en experimento MPTCP sobre red OpenFlow La topologia que se utilizó para realizar el experimento se muestra en la figura . Figura 11. Topologia utilizada en experimento MPTCP sobre red OpenFlow Se obtuvieron los siguientes resultados . En cada servidor hay instaladas 2 tarjetas de red 10 Gigabit Ethernet.MP-TCP 32 Figura 10. El trafico fue distribuido por 2 rutas (colores verde y rojo del diagrama).

Esto supondrá los beneficios que han sido descritos en el desarrollo de este trabajo. Figura 13.33 MP-TCP Figura 12. Escenario posible con IOS 7 . 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.

- Además. - Es importante que se tenga en cuenta el tema de la seguridad cuando se trabaja con el nuevo protocolo. 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. 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. se garantiza que siempre haya un flujo TCP en la conexión (si queda al menos un camino). solo Linux lo ha implementado en su kernel. .MP-TCP 34 VIII. puesto que hasta el momento no se encontró información que otro sistema lo soporte. - MPTCP es una solución que experimentalmente ha dado excelentes resultados puesto que al aumentar la cantidad de subflujos de un mismo tráfico. 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. el ancho de banda disponible aumenta considerablemente. 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.

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