MP-TCP

Autores: Diego Cruz Rubn Mora

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 SEALIZACIN

III. ARQUITECTURA BSICA PARA MP-TCP III.1. DESCOMPOSICIN FUNCIONAL DE MP-TCP III.2. III.3. III.4. III.5. III.6. III.7. III.8. DECISIN DE DISEO DE ALTO NIVEL BUFFER SEALIZACIN MANEJO DE CAMINO IDENTIFICACIN DE CONEXIN 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 CONEXIN (HIJACKING) ATAQUE MAN IN THE MIDDLE (MITM)

CASOS DE USO E IMPLEMENTACIONES

VIII. CONCLUSIONES IX. REFERENCIAS Y BIBLIOGRAFA

MP-TCP

OBJETIVOS
-

Conocer el funcionamiento del protocolo MP-TCP. Describir la arquitectura en la que se basa el funcionamiento de MP-TCP. Hacer una comparacin con TCP actual y resaltar ventajas y desventajas. Describir las aplicaciones actuales.

I.

INTRODUCCIN

Con la evolucin 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 podra usar correctamente, la experiencia del usuario final podra ser enormemente mejorada. Estas mejoras tambin reduciran la necesidad de gastos en infraestructura de la red.

El transporte Multipath permite alcanzar algunas metas del poleo de recursos haciendo uso simultneamente de caminos disjuntos (o parcialmente disjuntos) a travs de la red. Los dos principales beneficios de transporte multipath son los siguientes:

Incrementar la resistencia de la conectividad proveda por los mltiples 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 versin modificada de TCP que implementa transporte multipath y logra estas metas por poleo de caminos mltiples dentro de una conexin de transporte, transparentemente para la aplicacin. MP-TCP tiene como preocupacin principal el uso mltiple de caminos extremo a extremo, donde uno o ambos de los usuarios finales tienen mltiples tarjetas. Esto puede tener aplicaciones tambin donde los caminos mltiples existen dentro de una red y pueden ser manipulados por un usuario final, como usando diferente nmero de puertos con Equal Cost MultiPath (ECMP).

MP-TCP

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

A continuacin se pretende describir como objetivos: (i) Describir metas para un transporte multipath, metas para las que MP-TCP fue diseado; (ii) Presentar la arquitectura bsica para diseos 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 tpico para MPTCP. Dos hosts, A y B, estn comunicndose entre ellos. Estos hosts tienen multi-tarjeta y mltiples direcciones, proveyendo dos conexiones disjuntas a internet. Las direcciones de cada hosts estn 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 podra tener cualquier nmero de direcciones (1 o ms) en cada host, tantas como caminos disponibles entre hosts se quieran. Los caminos creados por esta combinacin de direcciones a travs de Internet no necesitan ser enteramente disjunto.

II.1.

METAS FUNCIONALES.

Mejorar el Throughput: MP-TCP debe soportar el uso concurrente de mltiples caminos. Para lograr los incentivos mnimos de desempeo para el despliegue, una conexin MP-TCP sobre mltiples caminos debe alcanzar el throughput no peor que una conexin TCP simple sobre el mejor camino elegido.

MP-TCP

Mejorar Resistencia: MT-TCP debe soportar el uso de mltiples caminos intercambiables para propsitos de resistencia, permitiendo que los segmentos se enven y reenven 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 distribucin del trfico a travs de caminos disponibles y respuestas a la congestin 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.

Adems, MP-TCP debe tener la caracterstica de negociacin automtica 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 extensin requerida, usndolas si puede y caso contrario automticamente regresa a la conexin TCP de camino nico.

II.2.

METAS DE COMPATIBILIDAD.

Adems de cumplir con las metas funcionales MP-TCP debe cumplir con las siguientes categoras de metas de compatibilidad.

Compatibilidad de Aplicacin.

MP-TCP debe seguir el mismo modelo de servicio que TCP, en orden, confiable, entrega orientada a byte. Adems, una conexin MP-TCP debe proveer la aplicacin con un throughput o resistencia no peor que la que se espera corriendo en una conexin 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 conexin TCP simple.

Para una sesin 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.

MP-TCP

Compatibilidad de la Red.

Requiere que la extensin 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 extensin 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 dbilmente. El uso de caminos mltiples no debe afectar a los usuarios que usan TCP simple en cuellos de botella compartidos, ms all del impacto que ocurrira 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 extensin de TCP con capacidades mutipath traer un nmero 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 travs de la combinacin de mecanismos de seguridad TCP existentes. Y de la proteccin contra las nuevas amenazas multipath identificadas.

III.

ARQUITECTURA BSICA PARA MP-TCP.

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

MP-TCP

Figura 2: Descomposicin de las funciones de transporte

Tng divide libremente la capa de transporte en capa de orientada a la aplicacin y orientada a la red, como muestra la figura 2. La capa orientada a la aplicacin Semantic implementa funciones impulsadas primordialmente por preocupaciones de soporte y proteccin de la comunicacin extremo a extremo de la aplicacin, mientras que la capa de red-orientada Flow+Endpoint implementa funciones como identificacin de fin de punto (usando nmero de puertos) y control de congestin. Estas funciones de redorientadas, mientras que tradicionalmente se encuentra en la ostensible capa de transporte extremo a extremo.

El diseo de arquitectura MP-TCP sigue la descomposicin de las Tng. MP-TCP, el cual provee compatibilidad de aplicacin a travs de la preservacin de semntica TCP-like de ordenamiento global de aplicacin de datos y confiabilidad, es una instanciacin de la capa semntica orientada a la aplicacin; mientras el subflujo del componente TCP, el cual provee compatibilidad de la red por aparicin y comportamiento como flujo TCP en la red, es una instanciacin de la capa Flow+Endpoint orientada a la red.

Como extensin del protocolo TCP, MP-TCP reconoce explcitamente cajas intermedias (middleboxes) en su diseo 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. DESCOMPOSICIN FUNCIONAL DE MP-TCP. MP-TCP hace uso de sesiones estndar TCP aparenta que est en la red, como trmino subflujo para proveer de transporte subyacente por camino, y as mantiene la

MP-TCP

compatibilidad de la red deseada. La informacin MP-TCP especfica es llevada en forma compatible TCP, este mecanismo es separado de la informacin actual que es transferida que podra 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 aplicacin la extensin MP-TCP para manejar mltiplos subflujos TCP debajo de ella. Para lograr esto debe implementar las siguientes funciones:

Manejo de camino: funcin para detectar y usar los mltiples caminos entre dos hosts. MP-TCP usa la presencia de mltiples direcciones IP en uno o ambos de los hosts como un indicador de esta. Las caractersticas del manejo de caminos del protocolo MP-TCP son los mecanismos para direccin de seal alternativa para hosts, y

mecanismos para la creacin de nuevos subflujos unidos a una conexin existente MPTCP.

Programacin del paquete: esta funcin rompe el byte stream recibido de la aplicacin en segmentos para ser transmitidos en uno de los subflujos disponibles. El diseo MP-TCP hace uso de paso de secuencia de datos, asociando segmentos enviados en diferentes subflujos para la numeracin de la secuencia del nivel de conexin, permitiendo a los segmentos enviados en diferentes subflujos ser correctamente reordenados en el receptor. El programador de paquetes es dependiente de informacin 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 funcin es tambin responsable para el reordenamiento del nivel de

MP-TCP

10

conexin en la recepcin 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 programacin de paquetes y los trasmite sobre el camino especfico, 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 aade sus propios nmeros de secuencia a los segmentos; estos suelen detectar y retransmitir prdida de paquetes en la capa de subflujo. En recepcin, el subflujo pasa sus datos reensamblados al componente de programacin de paquetes para reensamblar a nivel de conexin; el mapeo de secuencia de datos desde el componente de programacin de paquetes del emisor permite el reordenamiento del byte stream entero.

Control de Congestin: Esta funcin coordina el control de la congestin a travs de subflujos. Este algoritmo de congestin debe asegurar que la conexin MP-TCP no tome injustamente ms ancho de banda que un flujo TCP de camino simple en el cuello de botella compartido.

Estas funciones deben juntrselas de la siguiente manera. El administrador de caminos busca despus del descubrimiento (y si es necesario, inicializacin) de mltiples caminos entre dos hosts. El programador de paquetes luego recibe el stream de datos desde la aplicacin destinada por la red, y se encarga de las operaciones necesarias en este (como segmentacin de datos en segmentos de nivel de conexin, y aadiendo un nmero de secuencia al nivel de conexin antes de enviarlo en el subflujo. El subflujo luego aade su propio nmero de secuencia, ACKs 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 conexin y enva el stream de datos a la aplicacin. Finalmente, el componente de control de la congestin 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.

DECISIN DE DISEO DE ALTO NIVEL.

Aparentemente hay un amplio rango de decisiones cuando estas diseando una extensin multipath de TCP. Sin embargo, se menciona la siguiente lnea de diseo de alto nivel que se basa en la arquitectura bsica.

Secuencia de numeracin.

TP-TCP usa dos niveles de espacios de secuencias: Un nmero de secuencia a nivel de conexin y otro nmero de secuencia para cada subflujo. Esto permite segmentacin a nivel de conexin y reensamblamiento y retransmisin de la misma parte del espacio de secuencia de niel de conexin en diferente espaci de secuencia de nivel de subflujo.

La aproximacin alternativa usara un nmero de secuencia de nivel de conexin simple, con el cual se enva en mltiples subflujos. Esto tiene dos problemas: primero el subflujo individual aparecer para la red como sesin TCP con lagunas en los espacios de secuencia; esto puede molestar algunas cajas intermedias como lo son los sistemas de deteccin de intrusos, o ciertos proxies transparentes, e ira en contra de la meta de compatibilidad de la red. Segundo, el emisor no sera capaz de atribuir paquetes perdidos o recepciones por el camino correcto cuando el mismo segmento es enviado en mltiples caminos.

El emisor debe ser capaz de decir al receptor como reesnamblar los datos, para entregarlos a la aplicacin. Para lograr esto el receptor debe determinar cmo los datos de nivel de subflujo (llevando nmeros de secuencia de subflujo) mapea a nivel de conexin. Esto es referido a mapeo de secuencia de datos. Este mapeo puede ser representado como una tupla de (nmero de secuencia de datos, nmero de secuencia de subflujo tamao),

Una opcin para el mapeo de la seal d secuencia de datos podra ser utilizar los campos existentes en el segmento TCP (como nmero de secuencia de subflujo, tamao) y aadir solamente el nmero de secuencia de datos en cada segmento, por instancia, como una opcin TCP. Esto sera vulnerable, sin embargo, para las cajas intermedias que re segmenta o ensambla datos, no hay comportamiento especfico para incorporar opciones TCP. Si una sealada (nmero de secuencia de datos, tamao), esta seguir siendo vulnerable para cajas

MP-TCP

12

intermedias que incorporan segmentos y no entienden sealizacin MP-TCP as que no coescribir las opciones correctamente.

Por este problema potencial, la decisin de diseo 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 tamao) deben enviarse. Para reducir el encabezado, podra ser permisible para el mapeo para ser enviado peridicamente y cubierto ms que en un segmento simple. Adems la experimentacin es requerida para determinar que negociacin existe respecto a la frecuencia a la que el mapeo debera ser enviado. Esto tambin podra ser excluido enteramente en el caso de una conexin anterior ms que un subflujo utilizado, donde el espacio de secuencia de nivel de datos y nivel de subflujo es el mismo.

Retransmisiones y Fiabilidad.

Las caractersticas de reconocimiento MP-TCP en el nivel de conexin como en el nivel de subflujo, estn para proveer servicio de robustez a la aplicacin.

Bajo comportamiento normal, MP-TCP podra usar el mapeo de secuencia de datos y subflujos ACKs para decidir cundo un segmento de nivel de conexin fue recibida. La transmisin de ACKs TCP para un subflujo son manejadas enteramente al nivel de retransmisin de nivel de subflujo. Esto tiene cierta implicacin en semnticas extremo a extremo. Esto significara 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 conexin. Segundo, diferente al estndar TCP, un receptor no puede simplemente desechar segmentos fuera de orden si necesita (por ejemplo, debido a la presin de memoria. Bajo ciertas circunstancias, puede ser deseable para desechar segmentos despus de reconocerlos en el subflujo pero antes de entregarlos a la aplicacin, y esto puede ser facilitado por un reconocimiento a niel de conexin.

Adems, es posible concebir para que en algunos casos donde el reconocimiento de nivel de conexin pueda mejorar la robustez.

13

MP-TCP

Por lo tanto, para proveer una solucin TCP multipath completamente robusta, a MP-TCP para uso en Internet pblico debe tener la caracterstica de reconocimiento explcito de nivel de conexin, adicionalmente para reconocimientos de nivel de subflujo. El reconocimiento de nivel de conexin sera solamente requerido por la seal 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 nmero de espacios de secuencia duales.

La programacin de retransmisiones tendr impacto significante en la experiencia de los usuarios MPTCP. La actual especificacin MP-TCP sugiere que datos extraordinarios en subflujos que tienen timeout deben ser re-programador para transmisin en diferentes subflujos. Este comportamiento logra minimizar la desorganizacin cuando un camino se rompa, y usa el primer timeout como indicador. Versiones ms conservadoras sera usar un segundo o tercer timeout para el mismo segmento.

Tpicamente, rpida retransmisin en un subflujo individual no disparar retransmisiones en otro subflujo, adems esto puede ser deseable en ciertos casos, por ejemplo, para reducir los requerimientos de buffer de recepcin. Sin embargo, en todos los casos con retransmisiones en diferentes subflujos, los segmentos perdidos deben todava 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 recepcin al nivel de conexin, donde los segmentos son colocados hasta que son ordenados y pueden ser ledos por la aplicacin.

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 sera 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 duracin del RTO. Sera necesario el bfer de recepcin a nivel de conexin ms pequeo que podra 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 ms largo a lo largo de todos los subflujos.

Esto es un orden de magnitud ms que el bfer de recepcin requerido para una conexin simple, y es probablemente tambin costosa para propsitos prcticos. Uno requerimiento ms sensible es para evitar estancarse en ausencia de timeouts. De ah lo recomendado es que el bfer de recepcin sea.

2*sum(BW_i)*RTT_max,

Donde, RTT_max es el RTT ms largo a lo largo de todos los subflujos.

Este tamao de buffer asegura que los subflujos no se estanquen cuando hay retransmisiones rpidas disparadas en cualquier subflujo.

El tamao del bfer resultante debe ser lo pequeo suficiente para uso prctico.

Buffer del envo: el recomendado es el mismo tamao que el recomendado para recepcin. Esto es porque el emisor debe almacenar localmente los segmentos enviados pero no reconocidos por el nivel de conexin ACK. El tamao del bfer de envo importa particularmente para hosts que mantienen un largo nmero de conexiones en marcha. Si el bfer de envo requerido es muy largo, un host puede escoger solamente enviar datos en los subflujos rpidos, usando el subflujo lento solamente en caso de falla.

15

MP-TCP

III.4.

SEALIZACIN

Como MP-TCP usa TCP, sus mecanismos de transporte de subflujos, en conexiones MPTCP tambin inician como una conexin TCP simple. Sin embargo, esto debe sealar al peer que soporta MP-TCP y desea usar esa conexin. Adems se requiere sealizacin durante la operacin de la sesin MPTCP, como para reensamblar a lo largo de mltiples subflujos, y para informacin del otro host acerca de otra direccin IP disponible.

El protocolo MP-TCP diseado usara opciones TCP para esta sealizacin adicional, con estos mecanismos, la sealizacin 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 tpico, MP-TCP usa mltiples 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, seran suficientemente disjuntos para permitir multipath para lograr mejorar el throughput y robustez. El uso de mltiples direcciones IP es un simpe mecanismo que no requiere caractersticas adicionales en la red.

Mltiples diferentes pares de direcciones (origen, destino) seran usados como caminos selectores en la mayora de los casos. Sin embargo, cada camino ser identificado por un estndar five-tuple, el cual puede permitir la extensin 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 aadir nuevos subflujos para conexiones MP-TCP, MPTCP debe ser capaz de manejar caminos que aparezcan y desaparezcan durante el tiempo de vida de la conexin. El manejo de caminos es una funcin separada del programador de paquetes, interfaz de subflujo y funciones de control de congestin de MP-TCP, sera factible reemplazar el

MP-TCP

16

diseo basado en direcciones IP con un mecanismo de seleccin alternativa de caminos, sin cambios significativos en los otros componentes funcionales. En la figura 4. Se observan los caminos posibles para una conexin entre un cliente y un servidor, cada dispositivo con dos interfaces de red diferentes.

Figura 4. Caminos Disponibles Conexin Cliente - Servidor

III.6.

IDENTIFICACIN DE CONEXIN.

Como una conexin MP-TCP no se limita al tradicional 5-tuple (direccin y puerto origen, direccin y puerto destino, nmero de protocolo) para la entereza de su existencia, es deseable proveer un nuevo mecanismo para la identificacin de la conexin sera muy til tener un nico identificador con el cual se asocien los mltiples subflujos.

Cada conexin MP-TCP requiere un identificador de conexin en cada host, el cual es nico localmente dentro del host. La conexin 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 direccin especfica, donde las aplicaciones toman decisiones deliberadas del camino en uso.

17

MP-TCP

III.7.

CONTROL DE LA CONGESTION

El control de la congestin en presencia de mltiples trayectos significa que los sistemas adquieren un papel que se asocia normalmente con el enrutamiento, es decir, trasladar el trfico en caminos que eviten puntos de congestin, 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 prdidas 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 congestin en un ambiente MPTCP debe ser diseado para lograr una asignacin 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 congestin en cada ruta independiente, entonces se perder 4 veces los flujos. La idea de poder trasladar trfico entre diferentes caminos es que se pueda tener una determinada cantidad de trfico extremo a extremo y que se compense las tasas bajas de una ruta con el mayor trfico en otras.

Hay tres metas que los algoritmos de control de la congestin usados en la implementacin MPTCP: mejorar el throughput; no afectar a otros usuarios de la red; y balance de la congestin alejando trfico de los caminos ms congestionados. Para lograr estas metas, los algoritmos de control de la congestin 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 configuracin de la conexin original. b. Proveer la verificacin que los peer pueden recibir trfico en la nueva direccin antes de aadirla.

MP-TCP

18

c. Proveer proteccin contra la reproduccin.

Mecanismos adicionales han sido desplegados como parte de la pila estndar 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 proteccin similar. Adems TCP SYN cookies se desarrollaron para permitir al servidor TCP diferir entre la creacin del estado de la sesin del estado SYN_RCVD, y permanece sin estado hasta alcanzar el estado ESTABLISHED. MP-TCP debe, idealmente, continuar proveyendo la funcionalidad y como mnimo 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 informacin que puede ser llevada en el handshake. b) La necesidad para trabajar a travs de cajas intermedias resulta en la necesidad de manejar la mutabilidad de paquetes. c) El deseo de portar un break-before-make, se alcanza aadiendo subflujos (dentro de un limitado perodo 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 conexin, es decir, establece (negocia) una conexin antes de transmitir los datos y fiable porque asegura que la informacin sea recibida sin errores y en el mismo orden que se transmitieron (hace retransmisiones), tambin proporciona mecanismos para distinguir entre diferentes servicios o aplicaciones dentro de una misma maquina a travs de los puertos. TCP est documentado por el IETF en el RFC 793. En la siguiente figura se observa el proceso para establecer una conexin que usa TCP

19

MP-TCP

Figura 5. Establecimiento conexin TCP

En un kernel que tenga habilitado MPTCP, los componentes TCP se reemplazarn por componentes MPTCP y subflujos TCP para cada interfaz, los componentes TCP reciben los datos de una aplicacin (La aplicacin no necesita ser modificada), entonces MPTCP divide los datos en mltiples segmentos que se convertirn en subflujos TCP. Cada uno de estos subflujos se comporta como una conexin TCP normal en la red. MPTCP puede manejar rutas de diferente ancho de banda porque implementa un mecanismo de control de la congestin a travs de los subflujos, estos mecanismos garantizan que si hay congestin en alguna ruta, el trfico sea desviado por otro camino que presente menor congestin. Se hace balanceo de carga en la red.

En la figura 6. Se aprecia el proceso para realizar una conexin utilizando MPTCP

MP-TCP

20

Figura 6. Establecimiento conexin varios flujos con MP-TCP

Los componentes MPTCP realizan tres funciones Se encargan de la gestin de rutas mediante la deteccin y el uso de mltiples caminos desde un nodo origen a un nodo destino, cuando una conexin se establece los extremos realizan la negociacin de direcciones IP alternativas que sern las rutas adicionales. Divide el flujo de datos recibidos de la aplicacin en mltiples segmentos y los transmite por uno de los sub flujos disponibles. Estos segmentos estarn numerados para que al recibirlos se puedan ordenar correctamente y reconstruir los datos originales. Implementa control de congestin, hace balanceo de carga sobre los sub flujos (traslada el trfico a la ruta menos congestionada)

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

21

MP-TCP

Figura 7. Capas superiores modelo TCP/IP

La utilizacin 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 descripcin de estos beneficios.

V.

MEJORAS INTRODUCIDAS CON MPTCP

V.1. MEJORAS EN EL RENDIMIENTO Uno de los objetivos al aadir multicaminos a TCP es el de mejorar el rendimiento de una conexin de transporte haciendo balanceo de carga distribuido sobre sub flujos separados a travs de caminos diferentes. Es tambin objetivo explcito de MPTCP el de proveer una conexin que funcione al menos igual de bien como cuando se tiene un solo camino TCP. A continuacin se detalla los efectos en el rendimiento con MPTCP desde el punto de vista de una aplicacin:

V.2.

MEJORA EN TROUGHPUT

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

MP-TCP

22

entre dos puntos finales. Esto usualmente provee un ancho de banda ms grande para una aplicacin, aunque pueden existir excepciones debido al control dinmico de la congestin. Por ejemplo, si se pone en marcha un sub flujo en un periodo corto de tiempo, el troughput puede ser menor que el ptimo terico. Si hay cuellos de botella compartidos entre los flujos, entonces el algoritmo de control de la congestin en la mayora de los casos aseguraran que la carga est distribuida uniformemente entre las sesiones TCP regulares y multicaminos para que ningn usuario final reciba un peor rendimiento que cuando recibe un nico flujo TCP. Existen algunos casos extremos conocidos en que una actualizacin a MPTCP puede afectar a otros usuarios.

Adems, la flexibilidad de MPTCP para agregar y remover sub flujos segn cambios en los caminos disponibles podra conducir a variaciones del ancho de banda de conexin, las aplicaciones que se adaptan al ancho de banda disponible, como audio y video, pueden necesitar ajuste de sus parmetros para tener un mejor rendimiento.

El transporte de informacin de sealizacin MPTCP produce una baja sobre carga en la red. El uso de MPTCP en lugar de una sola conexin TCP resulta en un goodput [1] ms pequeo, adems si mltiples 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 reduccin de caudal ser insignificante en muchos escenarios de uso, y el protocolo contiene optimizaciones en su diseo de modo que esta sobrecarga es mnima. V.3. RETARDO

Los beneficios de MPTCP con respecto al troughput y a la capacidad de recuperacin (Resilience) pueden llegar a algunos costos en relacin con el retardo en la entrega de datos y retardos en el jitter. Si los retardos en los sub flujos que conforman una conexin MPTCP difieren, el Jitter perceptible para una aplicacin puede parecer como superior a los datos que se transmiten a travs de los subflujos. Aunque MPTCP asegurar el orden de entrega a la aplicacin, los datos entregados pueden ser a rfagas lo que es el caso ms usual cuando se tiene una sola conexin TCP, en particular en conexiones altamente asimtricas.

23

MP-TCP

Las aplicaciones con alto requerimiento de tiempo real pueden verse afectadas por tal escenario, una solucin es desactivar MPTCP para las aplicaciones ms sensibles al jitter, ya sea mediante el uso de una API o por otros medios definidos en las polticas del sistema.

Sin embargo el retardo actual y el jitter en el trasporte de datos sobre MPTCP depender de los algoritmos de control de congestin usados para enviar los datos, as como la heurstica para establecer y cerrar los sub flujos. Un emisor puede poner en prctica estrategias para reducir al mnimo el jitter visto por las aplicaciones, pero esto requiere una estimacin precisa de las caractersticas del trayecto. Si las decisiones de planificacin son suboptimas o si los supuestos sobre las caractersticas de los caminos resultan ser errneos, el jitter puede aumentar y afectar aplicaciones sensibles a los retardos. En general, para una aplicacin sensible al retardo es aconsejable seleccionar un algoritmo de control de congestin apropiado para sus necesidades de trfico.

Alternativamente, MPTCP

podra 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 mtodos de scheduling de trfico no causara variacin del retardo de la misma manera. Si uno de los sub flujos en el transporte de datos falla, las retransmisiones dentro de MPTCP podran afectar el retardo de la aplicacin. Sin embargo, sin MPTCP los datos o la conexin completa se hubieran perdido y otro mecanismo de fiabilidad, por ejemplo de recuperacin en el nivel de aplicacin, probablemente tendra 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 mltiples subflujos simultneos significa que si uno falla, todo el trfico se trasladar a los restantes subflujos y adems 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 recuperacin en comparacin con el uso de una sola conexin TCP mejora. MPTCP tambin 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 conexin MPTCP puede sobrevivir a una falta de disponibilidad o cambio de una direccin IP, por ejemplo debido a la cada de una interfaz. MPTCP cierra o reinicia la conexin MPTCP independientemente por subflujos individuales.

El fallo en un sub flujo puede ser causado por problemas dentro de la red que una aplicacin podra 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 conexin 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 conexin.

Aunque MPTCP es ms seguro que el TCP normal, el soporte para mltiples 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 mltiples direcciones IP en cada punto final.

Hay diferentes maneras de lograr mltiples rutas TCP en una conexin. Bsicamente, se necesita que los distintos segmentos de la comunicacin sean transmitidos a travs de interfaces (caminos) diferentes, permitiendo al remitente que utilice algn algoritmo para escoger las diferentes trayectorias para el trfico. Existen varias opciones para la escogencia de caminos, se pueden utilizar diferentes los siguientes saltos en una ruta, tambin se pueden emplear tneles a diferentes interfaces de salida.

En una comunicaciones TCP normal donde solo se tiene un camino para la conexin 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 trmino 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 continuacin 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 direccin IP (IP A). Un servidor que puede generar una cantidad suficiente de trfico (Por ejemplo, un servidor de videostreaming) que llamaremos la fuente (S) que tiene una direccin IP configurada (IP S), el objetivo (T) tambin tiene una direccin IP configurada (IP T).

En el primer paso de este tipo de ataques, el atacante (A) establece una conexin MPTCP con la fuente del trfico (Servidor S) y comienza a descargar una cantidad significante de paquetes. En la primera conexin solo se utiliza una direccin IP por cada extremo (IP A y IP S). Paso 2 una vez la descarga est en curso, el atacante (A) agrega la direccin IP T (del objetivo) como una de las direcciones habilitadas para la comunicacin. Como se agrega esta direccin IP depende del tipo de gestin de direcciones que emplee MPTCP. En la gestin de direcciones explicita el atacante (A) solo necesita enviar un paquete de sealizacin con la direccin del objetivo (IP T), en el modo implcito el atacante necesitara enviar un paquete con la direccin del objetivo como la direccin de origen. En esta etapa la conexin MPTCP todava tiene una sola direccin 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 direccin intenta conseguir la direccin de la fuente para enviar el trfico de la descargar en curso a la direccin 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 envan a IP A. Los detalles de este proceso dependen de como los datos son enviados a travs de diferentes caminos son negociados por medio de los ACKs, una posibilidad es que los ACKs para los datos enviados a travs de un par de direcciones determinadas deben venir en un paquete que contiene el mismo par de direcciones, si es as el atacante tendra que enviar ACKs utilizando paquetes que contienen la direccin del objetivo como direccin de origen para mantener el flujo del ataque, esto puede o no ser posible, dependiendo de los filtros a la entrada y la ubicacin del atacante. El atacante tambin debera adivinar el nmero de secuencia de los datos que estn 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 CONEXIN (HIJACKING)

El ataque de tipo secuestro de la comunicacin bsicamente usan el dinamismo en las direcciones IP en MPTCP para permitir a un atacante secuestrar una conexin, esto significa que la vctima de una conexin 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 continuacin:

27

MP-TCP

Figura 8. Escenario ataque de secuestro de conexion

Una conexin MPTCP est establecida entre el nodo 1 y el nodo 2, la conexin 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 comunicacin 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) alcanzarn 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 aplicacin 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 conexin 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 conexin, esto ser posbile en dependencia de la ubicacin del atacante. 2) Segmentos fluyen desde el nodo 2: Tan pronto como la direccin IP A es aceptada por el nodo 2 como parte del set de direcciones disponibles para la conexin MPTCP, el

MP-TCP

28

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

Un ataque relacionado que se puede lograr usando tcnicas similares sera 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 aade la direccion IP A como una direccion adicional para la conexin 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 comunicacin. La principal diferencia es que en este caso el atacante puede simplemente esnifar el contenido de la comunicacin que es transmitido a traves de l, y asu vez reenviar los datos a sus pares en la comunicacin, 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 versin estable V0.88 basada en el kernel de Linux v3.11. Los siguientes sitios web estn utilizando la implementacin 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 continuacin 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 estadsticas fueron registradas desde 2012.

Figura 8. Mapa de origen de conexin a servidor con MPTCP

MP-TCP

30

Investigadores del IP Networking Lab hicieron una pequea 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 aplicacin denominada dem- screensaver en un servidor distante que tiene habilitado MPTCP. Cuando se desconecta el trafico Ethernet y WiFi gracias a MPTCP la conexin 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.

Conexin 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 demostracin para poner a prueba los lmites de desempeo de MPTCP utilizando interfaces 10 Gbps, se emple una configuracin como la que se muestra a continuacin:

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.

Conexin 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 aadi 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

34

VIII.

CONCLUSIONES

Las exigencias actuales requieren de la implementacin de nuevos mecanismos para soportar el aumento del trfico que fluye por la red sin tener la necesidad de instalar hardware costoso.

MPTCP es una solucin que experimentalmente ha dado excelentes resultados puesto que al aumentar la cantidad de subflujos de un mismo trfico, el ancho de banda disponible aumenta considerablemente.

Adems, se garantiza que siempre haya un flujo TCP en la conexin (si queda al menos un camino), lo cual garantizar un camino para enviar la informacin haciendo mucho ms robusta la red y con la capacidad de recuperarse ante fallos o congestin en algunos de sus caminos. Esto supone gran inters 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 dinmico el intercambio de informacin en el establecimiento de conexiones entre un cliente y un servidor.

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

35

MP-TCP

IX.

REFERENCIAS Y BIBLIOGRAFA

[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] Sbastien 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/ Pgina web del proyecto implementacin 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/ Pgina video resultado experimentos [12] http://www.youtube.com/watch?v=VMdPI9Cfi9k/ Pgina video resultado experimentos