MP-TCP

Autores:

Diego Cruz

Rubn Mora

3 MP-TCP

NDICE

OBJETIVOS

I. INTRODUCCION

II. ESCENARIO DE REFERENCIA

II.1. METAS FUNCIONALES

II.2. METAS DE COMPATIBILIDAD

II.3. METAS DE SEGURIDAD

III.4. SEALIZACIN

III. ARQUITECTURA BSICA PARA MP-TCP

III.1. DESCOMPOSICIN FUNCIONAL DE MP-TCP

III.2. DECISIN DE DISEO DE ALTO NIVEL

III.3. BUFFER

III.4. SEALIZACIN

III.5. MANEJO DE CAMINO

III.6. IDENTIFICACIN DE CONEXIN

III.7. CONTROL DE LA CONGESTION

III.8. SEGURIDAD

IV. COMPARACION CON TCP ESTANDAR

V. MEJORAS INTRODUCIDAS CON MP-TCP

V.1. MEJORA EN EL RENDIMIENTO

V.2. MEJORA EN TROUGHPUT

V.3. RETARDO

V.4. CAPACIDAD DE RECUPERACION DE LA RED (RESILIENCE)

VI. CONSIDERACIONES DE SEGURIDAD

VI.1. ATAQUES TIPO FLOODING

VI.2. ATAQUES TIPO SECUESTRO DE CONEXIN (HIJACKING)

VI.3. ATAQUE MAN IN THE MIDDLE (MITM)

VII. CASOS DE USO E IMPLEMENTACIONES

VIII. CONCLUSIONES

IX. REFERENCIAS Y BIBLIOGRAFA

MP-TCP 4

OBJETIVOS

- Conocer el funcionamiento del protocolo MP-TCP.

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

- Hacer una 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).

5 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 6

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.

7 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 next-

generation).

MP-TCP 8

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 red-

orientadas, 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

9 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 MP-

TCP.

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 MP-

TCP 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