Printer Friendly

Congestion control mechanism for data transfers in multiple Multicast/Mecanismo de control de congestion para transferencias de datos en Multicast multiple.

1. Introduccion

En el campo de la informatica, las comunicaciones permiten el intercambio de datos entre computadores. En los inicios, la comunicacion se realizaba entre una unica fuente y un unico destino. Con la evolucion constante de las tecnologias de comunicacion se ha alcanzado un progreso notable permitiendo el envio de datos desde una fuente a multiples destinos simultaneamente, conocido como comunicacion multicast. La utilizacion y aprovechamiento de estas comunicaciones siguen teniendo auge en la actualidad y continuan siendo un tema de interes para la investigacion. La comunicacion que se realiza en una red de computadores es esencial para los sistemas actuales que requieren transferencias entre estos, por citar un ejemplo se mencionan los sistemas de almacenamiento distribuido. Por otro lado, en (Wittmann & Zitterbart, 2000) se muestra un ejemplo de la contribucion de las comunicaciones multicast como exito importante.

Habilitar el trafico multicast implica utilizar el protocolo UDP para el transporte de los datos. Esto tiene como desventaja que no existe fiabilidad en la entrega de los datos. A diferencia del protocolo TCP que es un protocolo orientado a conexion y que mantiene sus propios mecanismos (Ait-Hellal & Altman, 2000; Ha, Rhee, & Xu, 2008; Leith, Shorten, & McCullagh, 2008; Xu, Harfoush, & Rhee, 2004) que garantizan la entrega de los datos a todos los destinos. Aunque al utilizar UDP para permitir el trafico multicast garantiza la entrega a diferentes destinos simultaneamente con menor consumo de recursos de computo, existen dos desventajas destacables: 1) perdida de paquetes: es posible la perdida de paquetes debido a la saturacion en la red, ademas de que se trata de un protocolo no orientado a conexion; 2) congestion: la falta de mecanismos para ajustar la tasa de envio puede dar lugar a la congestion de la red. Consecuentemente, para el desarrollo de aplicaciones basadas en multicast es necesario considerar aspectos de: fiabilidad, control de flujo, control de congestion y gestion de grupos.

El mecanismo de control de congestion permite prevenir la saturacion en la red (especificamente en el conmutador) o en el bufer de los nodos receptores (tipicamente debido a los discos lentos--HDD). En un entorno multicast es conveniente conocer informacion detallada de los receptores, tal como, capacidad actual de bufer de recepcion, direcciones multicast desde donde se reciben datos, velocidad de escritura en disco (disco HDD o SSD), etc., con esto se facilita el flujo de datos desde varios emisores y utilizar esta informacion como medida preventiva para la congestion, de tal manera que sea posible garantizar la fiabilidad en la entrega de los datos a todos los receptores. Como ejemplo, en un sistema de almacenamiento distribuido el control de congestion juega un papel importante debido a que el trafico generado por estos sistemas suele ser elevado y persistente en la red cuando se trata de envios muy grandes como es el caso del sistema de ficheros Hadoop Distributed File System (HDFS) disenado para almacenar conjuntos de datos muy grandes de manera confiable y transmitirlos a un ancho de banda alto a las aplicaciones de los usuarios (Borthakur, 2008; Shvachko, Kuang, Radia, & Chansler, 2010). Al igual aplicaciones en entornos tales como (Diaz, Munoz, 2018; Palos-Sanchez, Arenas-Marquez, Aguayo-Camacho, 2017) se podrian beneficiar.

El presente articulo se centra en la implementacion de un mecanismo de control de congestion para comunicaciones multicast multiple evaluado en un entorno real de red de ordenadores, es decir, se evalua con trafico real, a diferencia de las diversas propuestas existentes en la literatura de mecanismos de control de congestion que se desarrollan en entornos simulados.

En la siguiente seccion se mencionan algunos trabajos que tienen relacion con nuestra propuesta. Posteriormente en la seccion 3., se describe en mayor detalle el algoritmo propuesto. Seguido de la seccion 4 con la evaluacion y analisis de la propuesta y, al finalizar se dan las conclusiones observadas en el presente articulo.

2. Trabajo relacionado

En la literatura revisada (Fall & Stevens, 2011; Wittmann & Zitterbart, 2000) se ilustra que los mecanismos de control de congestion son basados en ventana (window-based) y en tasa de envio (rate-based) y que son ampliamente utilizados por el protocolo TCP, tales como BIC (Xu et al., 2004), CUBIC, Reno, Vegas, por mencionar algunos.

Con el fin de dar a conocer un poco mas el campo de aplicacion de las comunicaciones multicast, en el presente trabajo se ha analizado una serie de protocolos de comunicacion (mejor conocidos como Protocolo Multicast Fiable, RMP--Reliable Multicast Protocol), especificamente se muestra el mecanismo de control de congestion implementado, segun (Fall & Stevens, 2011; Wittmann & Zitterbart, 2000), para cada uno de estos protocolos. Como se puede observar en la Tabla 1, los protocolos PGM (Gemmell, Montgomery, Speakman, & Crowcroft, 2003), RMTP (Paul, Sabnani, Lin, & Bhattacharyya, 1997) y TMTP (Yavatkar, Griffoen, & Sudan, 1995) utilizan implementaciones propias o no especifican sobre que mecanismo han basado la implementacion, mientras que RDCM (D. Li et al., 2014) y NORM (Adamson, Bormann, Handley, & Macker, 2009) se enfocan en los principios de BIC y TCP-Friendly, respectivamente, adaptados a comunicaciones multicast. En cambio, los protocolos (no se mencionan en la Tabla 1) CooPNC (Miliotis, Alonso, & Verikoukis, 2014), VCMTP (J. Li & Veeraraghavan, 2012), LBRM (Holbrook, Singhal, & Cheriton, 1995) y en (Kasera, Hjalmtysson, Towsley, & Kurose, 2000) no especifican implementacion de mecanismo de control de congestion.

A continuacion, se describe especificamente los algoritmos de control de congestion expuestos en la Tabla 1.

RDCM mantiene un control de congestion ajustando la tasa de envio del emisor donde la tasa de envio no debe ser mayor a la tasa de recepcion del lado receptor. Para ello, se implementa un mecanismo de control de congestion basado en ventana donde cada receptor mantiene una ventana de congestion individual. El tamano de la ventana se actualiza usando el algoritmo BIC (Xu et al., 2004) y la perdida de paquetes se usa como senal de congestion. Idealmente, cada receptor puede: a) detectar inmediatamente perdida de paquetes en el momento que ocurre, b) actualizar la ventana de congestion y enviar al nodo emisor.

Por otro lado, en el protocolo NORM se especifica un mecanismo de control de congestion, NORM-CC, basado en el esquema de TCP-Friendly multicast (TFMCC). La transmision de datos en NORM se basa en tasa de envio a diferencia de los algoritmos de control de congestion basados en ventana como es el caso de TCP. El funcionamiento de NORM-CC basicamente el receptor que experimenta perdida de paquetes que corresponde a la tasa de envio calculada mas baja se identifica como el receptor actual con mayor limitacion de recepcion de paquetes (Current Limiting Receiver--CLR). Como medida principal para el funcionamiento del algoritmo de control de congestion, el emisor en NORM transmite mensajes periodicamente que contienen informacion de control para conocer el estado de los receptores. Estos responden con mensajes de retroalimentacion para determinar el estado de congestion y con ello ajustar la tasa de envio de los emisores.

Mientras en el protocolo PGM se presenta un esquema de control de congestion, PGMCC, para comunicaciones multicast de tasa de envio unica (single-rate) compatible con TCP. PGMCC es un mecanismo de control de congestion basado en ventana y tiene como objetivo principal hacer que el emisor no transmita mas rapido que el receptor mas lento dentro del sistema. PGMCC funciona de tal manera que el emisor monitorea continuamente la informacion recibida en mensajes NAK desde los receptores. La informacion que proporcionan los receptores es fundamental para PGM y consta de: a) identidad del receptor, b) ultimo numero de secuencia recibido, y c) tasa de perdida de paquetes en el nodo local.

En cuanto al protocolo RMTP, utiliza un mecanismo de control de congestion basado en ventana donde el emisor utiliza una ventana de congestion cong_win para recudir la velocidad de transmision cuando existe congestion en el sistema. El mecanismo implementado utiliza un procedimiento de ajuste lineal de ventana llamado slow-start que se utiliza en implementaciones de TCP. Basicamente, el emisor usa un inicio lento en espera de reconocimientos positivos (ACK) desde los receptores.

En el protocolo TMTP utiliza una combinacion de tecnicas basadas en tasa de envio y en ventana. El componente basado en tasa de envio prohibe a los emisores enviar datos a una tasa mayor que la tasa maxima de transmision predefinida. La tasa maxima de transmision se define al momento de crear el grupo multicast y nunca cambia. Mientras que, en el mecanismo basado en ventana disminuye la tasa de envio dividiendo el tamano de la ventana y retrasando las retransmisiones el mayor tiempo posible, lo cual aumenta la posibilidad de recibir un acuse ACK de recibido.

Como se puede observar en el analisis previo, las implementations se realizan siguiendo los principios de los algoritmos de control de congestion utilizados en TCP. Al mismo tiempo, las implementaciones tienen un enfoque de transmision de datos en el que un emisor envia datos a diferentes receptores, tal como se muestra en la Figura 1., y en ocasiones utilizan una configuracion en arbol para hacer la distribucion de los datos (D. Li et al., 2014). En cambio, en el escenario de estudio para evaluar nuestra propuesta se busca utilizar al maximo todos los recursos existentes en el sistema de tal manera que los nodos tengan las funciones de emisor/receptor. Por lo tanto, nuestro mecanismo de control de congestion analiza constantemente el estado de los nodos, del conmutador y considera la tecnologia de almacenamiento utilizada para ajustar la tasa de transferencia desde los emisores.

3. Mecanismo de control de congestion

Tipicamente, los sistemas actuales de almacenamiento distribuido se ejecutan en entornos de cluster de computadores, donde las transferencias de datos son elevadas. Aunado a esto, cuando existen multiples transferencias multicast simultaneamente, la perdida de paquetes se podria originar cuando:

* El bufer del conmutador se satura debido al tamano pequeno de estos (en nuestro caso 1 Mbyte).

* El sistema operativo no tiene la capacidad de gestionar los paquetes recibidos.

* La aplicacion no puede procesar todo el trafico multicast cuando se utilizan discos lentos.

Siendo asi, en el presente trabajo se propone un mecanismo de control de congestion basado en ventana para escenarios donde se requiere hacer multiples transferencias multicast. Ademas, el mecanismo propuesto monitorea constantemente el estado del bufer del conmutador y la tecnologia de almacenamiento utilizada en el sistema, tal como se muestra en la Figura 2, en la que se asume que, en la configuracion un nodo receptor podria recibir datos desde uno, dos o tres emisores simultaneamente.

3.1. Detalles de la implementacion

La implementacion se ha desarrollado en lenguaje C en la distribucion CentOS de Linux. Se ha desarrollado la codificacion del cliente y del servidor donde reside el mecanismo de control de congestion propuesto. Ambas aplicaciones utilizan sockets UDP para habilitar el trafico multicast. Basicamente los clientes, reciben datos y los escriben en disco, y cada determinado tiempo envian informacion de control para ajustar la tasa de envio por el mecanismo de control de congestion propuesto en el lado de los emisores.

La informacion de control se envia desde los receptores a los emisores a traves de un paquete Broadcast (ver Figura 3).

Los campos de la Figura 3 se describen a continuacion para una mejor comprension del funcionamiento del mecanismo de control propuesto.

1. marca de tiempo: almacena la marca de tiempo cuando el algoritmo prepara el paquete Broadcast a enviar.

2. ultimo paquete recibido (upr): almacena la secuencia del ultimo paquete recibido.

3. total de paquetes recibidos (tpr): contabiliza el total de paquetes recibidos en el socket.

4. total de paquetes perdidos (tpp): contabiliza el total de paquetes perdidos.

5. bytes escritos en disco (bed): almacena el total de bytes escritos en el disco.

El mecanismo de control de congestion es usado para prevenir o evitar la congestion de la red. Para lograrlo se apoya del uso de:

* reconocimientos negativos (NAK): de tal manera que los receptores solo envian solicitud de retransmision cada vez que se pierde un paquete.

* ventana de congestion: se utiliza una ventana de congestion adaptativa de acuerdo a la configuracion del sistema, primordialmente cuando los receptores se asocian a diferentes direcciones multicast (descrito en la seccion 3).

Debido al tamano reducido del bufer del conmutador, este podria ser la principal causa de perdida de paquetes cuando los emisores envian datos a la maxima capacidad de envio (en nuestro caso se ha utilizado una red Gigabit que puede alcanzar una tasa de envio de hasta 120MB/s en cada emisor). En el algoritmo, para resolver esta situacion se aprovecha la informacion de control que se envia desde los receptores a los emisores, de tal manera que se calcula la diferencia upr (numero secuencia del ultimo paquete recibido en el receptor) y upe (numero de secuencia del ultimo paquete enviado en el emisor). La siguiente ecuacion simple ilustra el calculo de la diferencia mencionada: ATx [R.sub.x] = upr--upe y se calcula en el lado del emisor.

El mecanismo de control de congestion se calcula en el lado del emisor y de manera periodica recibe informacion de control desde los receptores. Cada paquete con informacion de control (Figura 3) se computa en tiempo real por cada hebra de recepcion en cada receptor y se envia a los emisores y la informacion solo se procesa en los emisores correspondientes. Una vez que la informacion sea procesada en el mecanismo de control de congestion de los emisores, se calcula lo siguiente considerando el numero de emisores: 1

1. tasa maxima de envio de datos (o tasa de envio critica) sin perdida de paquetes, la tasa de envio se ajusta dinamicamente y se incluye un retardo de tiempo TCWND entre cada CWND.

2. tamano de ventana de congestion (CWND) optimo.

3. ancho de banda de red y de escritura en disco de los receptores.

En cuanto al funcionamiento del algoritmo propuesto en este articulo, la Figura 4 ilustra la funcion basica que se realiza en la propuesta. Como se ha mencionado anteriormente, el mecanismo de control de congestion se ejecuta en el lado de los emisores y recibe como parametros de entrada la informacion de control que se envia desde los emisores. Al momento de iniciar se crea la funcion manejador_brodcast() que se utiliza para recibir la informacion de los receptores, con la informacion se calcula: el numero de emisores (n_emisores <-sumatoria_i) en cada receptor y el ancho de banda agregado (BWr <sumatoria_BWi) que en la marca de tiempo recibe el receptor, valores optimos para CWND y Tcwnd. Si el numero de emisores en determinado receptor es 1 (n_emisores = 1) el algoritmo asigna los valores mas optimos de CWND y para calcular Tcwnd se asigna T_1 si buffer < 80% (es decir, si el bufer de recepcion tiene menos del 80% de ocupacion), en caso opuesto se Tcwnd = T_1w.

Cuando n_emisores > 1 el algoritmo asume que existen 2 o hasta 3 emisores (3 emisores es el maximo permitido en este estudio), por lo cual, la probabilidad de congestion es mayor. Consecuentemente, el algoritmo asigna un nuevo valor de CWND. Aunado a esto, el algoritmo calcula un nuevo valor para Tcwnd, de tal manera que, si buffer < 80%, Tcwnd = t1 y en caso contrario se asigna tiw. Siendo asi, Tcwnd (Ver Figura 5) es el retardo que agrega el algoritmo entre cada ventana de envio y, se usa T_1 y t1 son los retardos utilizados para conseguir una tasa maxima de envio de datos desde los emisores, mientras que T_1w y t1w se utilizan para enviar datos a una tasa minima de envio.

Con el fin de detectar congestion en el conmutador, el algoritmo compara el ancho de banda de los receptores con el ancho de banda critico, es decir, el ancho de banda de recepcion maximo permitido en los receptores (BWr > BW_critico) y la diferencia [DELTA][T.sub.x]_[R.sub.x] con el umbral_[T.sub.x]_[R.sub.x] ([DELTA][T.sub.x]_[R.sub.x] > umbral_[T.sub.x]_[R.sub.x]). Si una de las dos condiciones se cumple, el algoritmo asigna nuevos valores de CWND y Tcwnd para disminuir la tasa de envio y con ello evitar congestion.

Con esta medida, el mecanismo propuesto permite reducir considerablemente la perdida de paquetes porque el control de congestion puede ralentizar la tasa de envio desde los emisores. Como idea principal, se pretende evitar la perdida de paquetes para impedir las retransmisiones que en muchas ocasiones puede ser innecesaria si el algoritmo tiene la funcionalidad adecuada.

4. Evaluacion del algoritmo

En la literatura es comun encontrar propuestas que son evaluadas en entornos simulados. En nuestro caso, con el fin de mostrar resultados reales, se ha evaluado el algoritmo en un entorno de cluster de computadores donde se realizan transferencias por otras aplicaciones principalmente con conexiones TCP.

4.1. Configuracion

La configuracion se distingue de diferentes grupos multicast donde la cantidad se determina por el numero emisores. Es decir, cada emisor envia datos a una determinada direccion multicast, y forma un grupo con hasta tres nodos receptores (se determina el valor de tres receptores por cuestiones de diseno del escenario de evaluacion).

Los nodos se interconectan por una red de 1Gbps a traves de un conmutador Dlink DGS1248T con un bufer de 1Mbyte y tiene la capacidad de reenviar hasta 71.4 Mpaquetes/s. La configuracion de cada nodo consta de 2 CPU Intel Xeon E5320 a 1.87GHz, Memoria RAM de 8GB, Sistema Operativo Linux distribucion CentOS 6.6. En cuanto a los discos de almacenamiento se incorporan discos de estado solido SSD Kingston de 120GB, Firmware 521ABBFo y una tasa de escritura maxima de 450MB/s.

4.2. Experimentos y resultados

Se ha determinado que cada nodo se asociara a tres direcciones multicast, de tal manera que constantemente recibe paquetes desde tres diferentes emisores. Lo anterior supone un evento critico debido a la poca capacidad del bufer del conmutador e incrementa la probabilidad de perdida de paquetes.

Segun un estudio previamente realizado para definir el tamano de paquete para este escenario, se define como tamano_paquete = 8KB. Ademas, se ha estudiado para obtener el mejor tamano de CWND, siendo el valor optimo CWND = 3. Con estos valores alcanzados, el algoritmo de control de congestion practicamente evita la perdida de paquetes con un ancho de banda considerablemente aceptable segun el escenario de estudio.

4.3 Congestion en conmutador: [DELTA][T.sub.x]_[R.sub.x]

Como primer analisis realizado, y de acuerdo a la configuracion planteada, ademas considerando los dispositivos de almacenamiento en los receptores se llevo a cabo la evaluacion del conmutador, de tal manera que el algoritmo de control de congestion propuesto determine el mejor funcionamiento de acuerdo a la tasa de envio registrada en los receptores. En la Figura 6 se puede visualizar la prediccion del algoritmo que calcula el estado de saturacion del conmutador cuando los emisores envian datos a la maxima capacidad posible. El porcentaje de perdida de paquetes alcanza los maximos valores (casi el 100%) cuando la tasa de envio de los emisores es alrededor de 120MBps (en la Figura 6 se muestra la sumatoria de ancho de banda que registra un receptor) de tal manera que los receptores registran una minima tasa de recepcion de paquetes. En funcion de que el algoritmo detecta la perdida de paquetes con informacion de control de los receptores, los emisores disminuyen la tasa de envio hasta alcanzar la tasa de envio optima y asi disminuir la perdida de paquetes a causa de saturacion en el conmutador. Mientras el valor [DELTA][T.sub.x]_[R.sub.x] sea menor, no existe congestion en el conmutador.

4.4.Ganancia de ancho de banda [SIGMA][BW.sub.r] + [BW.sub.env]

De acuerdo a los resultados observados en la Figura 6 y, considerando que el algoritmo, en primer lugar, tiene como objetivo evitar la perdida de paquetes, a continuacion se presentan resultados de ganancia de ancho de banda.

En la Figura 7 se muestra el ancho de banda obtenido por un receptor considerando la sumatoria de recepcion desde todos los emisores a los que se ha asociado para recibir informacion. En la Figura 7 se representa:

* [BW.sub.max]' maximo ancho de banda teorico disponible en el nodo para envio y recepcion.

* [BW.sub.env], maxima tasa de envio como nodo emisor.

* [SIGMA][BW], sumatoria del ancho de banda de recepcion, en este caso, simultaneamente el nodo recibe informacion desde 3 emisores con una tasa de envio de [+ o -]22MB/s.

* [SIGMA] BW + [BW.sub.env], total de ancho de banda que consume el nodo en envio y recepcion simultaneamente.

En la evaluacion se ha verificado la tasa de perdida de paquetes en donde predomina una tasa del 0% con algunos valores que alcanzan el 0.001%. En la evaluacion aqui presentada, cada nodo consume aproximadamente [+ o -] 80MB/s de ancho de banda considerando que en el entorno de evaluacion se ejecutaban otras aplicaciones que consumian ancho de banda de la red.

4.5. Ancho de banda de emisor/receptor y perdida de paquetes

Segun los valores optimos obtenidos en la subseccion 4.2, en la Figura 8 se representa el ancho de banda [SIGMA][BW.sub.emisores] como la capacidad maxima de envio de los emisores (para mayor ilustracion, se muestra la sumatoria de dos emisores) y por otro lado se obtiene el ancho de banda agregado [SIGMA][BW.sub.r] del receptor. En este caso el algoritmo, agrega un retardo [T.sub.cwnd] hasta evitar la perdida de paquetes (en los estudios realizados la tasa de perdida de paquetes no superaba el 0.001%) ver Figura 9.

En la evaluacion, se ha conseguido evitar la perdida de paquetes a una tasa de envio de los emisores de 20MB/s y una tasa de recepcion agregado de 40MB/s como se observa en la Figura 8.

De igual manera, se ha realizado un analisis con tamano de ventana CWND=4 con el fin de verificar el comportamiento del algoritmo y del ancho de banda obtenido tanto en emisor y receptores. Aumentar el tamano de ventana implica un ligero incremento en el trafico de la red y, para evitar la perdida de paquetes es necesario agregar un retardo [T.sub.cwnd] mayor y asi ralentizar por un lado la tasa de envio. En la Figura 10 se puede observar la caida en la tasa de envio en emisores y consecuentemente en la tasa de recepcion. Y, en la Figura 11 se observa el porcentaje de tasa de perdida de paquetes con el tamano de ventana CWND=4 utilizado en estos resultados.

4.6. Ancho de banda en disco [BW.sub.disco]

Respecto a los discos utilizados, y siguiendo como enfoque principal de aplicacion donde un sistema de almacenamiento distribuido garantice la disponibilidad de los datos para las aplicaciones, es necesario asegurar la escritura de los datos en el disco. Con la funcion fdatasync() se puede lograr tal fin. De tal manera que, se agrega un parametro sync_size = 32 paquetes a considerarse en el mecanismo de control de congestion. Es decir, la funcion fdatasync() escribe los datos en disco cada 256KB. El maximo ancho de banda promedio en los discos SSD utilizados alcanzan hasta 120MB/s para nuestra configuracion, ver Figura 12.

Como se puede observar, el comportamiento de los dispositivos de almacenamiento, en este caso discos SSD dan soporte al algoritmo de control de congestion evitando la saturacion y por consecuencia perdida de paquetes en los receptores al momento de realizar las escrituras simultaneas de los paquetes de datos recibidos.

5. Conclusiones

En las redes de datos, con el crecimiento de trafico de informacion se hace necesario implementar mecanismos que aseguren la entrega a todos los destinatarios. Los enfoques que existen en la literatura no consideran una orientacion para implementarse en sistemas de almacenamiento distribuido. Por tal motivo, en el presente trabajo se presento el diseno y evaluacion de rendimiento de un nuevo algoritmo de control de congestion basado en ventana (window-based) para comunicaciones de datos en entornos multicast multiple donde los nodos del sistema actuan como emisores y receptores de datos. El algoritmo constantemente evalua el estado de saturacion del conmutador y de los nodos receptores considerando la tecnologia de almacenamiento utilizada, en este caso discos SSD. Se realizaron evaluaciones de rendimiento en un entorno real simulando una capa de almacenamiento que provee de informacion a transmitir. En los resultados, el algoritmo consigue mantener una nula o reducida perdida de paquetes al mismo tiempo que el ancho de banda de red agregado se mantiene estable y considerablemente alto sin consumir el ancho de banda disponible por las interfaces de red.

Recebido/Submission: 25/08/2018

Aceitacao/Acceptance: 18/11/2018

Referencias

Adamson, B., Bormann, C., Handley, M., & Macker, J. (2009). NORM: Nack-Oriented Reliable Multicast Transport Protocol, DOI: 10.17487/RFC5740

Ait Hellal, O., & Altman, E. (2000). Analysis of TCP vegas and TCP reno. Telecommunication Systems, 15(3-4), 381-404. DOI: 10.1023/A:1019159332202

Borthakur, D. (2008). HDFS architecture guide. Retrieved from: https://hadoop. apache.org/docs/r1.2.1/hdfs_design.pdf.

Diaz, O., & Munoz, M. (2018). Implementacion de un enfoque DevSecOps+ Risk Management en un Centro de Datos de una organizacion Mexicana. RISTI-Revista Iberica de Sistemas e Tecnologias de Informacao, (26), 43-53. DOI: 10.17013/risti.26.43-53

Fall, K. R., & Stevens, W. R. (2011). TCP/IP illustrated, volume 1: The protocols. Boston: Addison-Wesley.

Gemmell, J., Montgomery, T., Speakman, T., & Crowcroft, J. (2003). The PGM reliable multicast protocol. IEEE Network, 17(1), 16-22. DOI: 10.1109/MNET.2003.1174173

Ha, S., Rhee, I., & Xu, L. (2008). CUBIC: A new TCP-friendly high-speed TCP variant. ACM SIGOPS Operating Systems Review, 42(5), 64-74. DOI: 10.1145/1400097.1400105

Holbrook, H. W., Singhal, S. K., & Cheriton, D. R. (1995). Log-based receiver-reliable multicast for distributed interactive simulation. ACM SIGCOMM Computer Communication Review, 25(4), 328-341. DOI: 10.1145/217391.217468

Kasera, S. K., Hjalmtysson, G., Towsley, D. F., & Kurose, J. F. (2000). Scalable reliable multicast using multiple multicast channels. IEEE/ACM Transactions on Networking, 8(3), 294-310. DOI: 10.1109/90.851976

Leith, D. J., Shorten, R. N., & McCullagh, G. (2008). Experimental evaluation of cubicTCP. In Proceedings of the 6th International Workshop on Protocols for Fast Long-Distance Networks (PFLDnet 2008), 5-7.

Li, D., Xu, M., Liu, Y., Xie, X., Cui, Y., Wang, J., & Chen, G. (2014). Reliable multicast in data center networks. IEEE Transactions on Computers, 65(8), 2011-2024. DOI: 10.1109/TC.2013.91

Li, J., & Veeraraghavan, M. (2012). A reliable message multicast transport protocol for virtual circuits. In International Conference on Communications, Mobility, and Computing (CMC), 119-123.

Miliotis, V., Alonso, L., & Verikoukis, C. (2014). CooPNC: A cooperative multicast protocol exploiting physical layer network coding. Ad Hoc Networks, 14, 35-50. DOI: 10.1016/j.adhoc.2013.11.004

Palos-Sanchez, P. R., Arenas-Marquez, F. J., & Aguayo-Camacho, M. (2017). La adopcion de la tecnologia cloud computing (SaaS): efectos de la complejidad tecnologica vs formacion y soporte. RISTI-Revista Iberica de Sistemas e Tecnologias de Informacao, (22), 89-105. DOI: 10.17013/risti.22.89-105

Paul, S., Sabnani, K. K., Lin, J., & Bhattacharyya, S. (1997). Reliable multicast transport protocol (RMTP). IEEE Journal on Selected Areas in Communications, 15(3), 407-421. DOI: 10.1109/49.564138

Shvachko, K., Kuang, H., Radia, S., & Chansler, R. (2010). The hadoop distributed file system. In IEEE 26th Symposium On Mass Storage Systems and Technologies (MSST), 2010, (pp. 1-10). DOI: 10.1109/MSST.2010.5496972

Wittmann, R., & Zitterbart, M. (2000). Multicast communication: Protocols, programming, & applications. Amsterdam: Elsevier.

Xu, L., Harfoush, K., & Rhee, I. (2004). Binary increase congestion control (BIC) for fast long-distance networks. In INFOCOM 2004. Twenty-Third Annual Joint Conference of the IEEE Computer and Communications Societies, (pp. 4 2514-2524). DOI: 10.1109/INFCOM.2004.1354672

Yavatkar, R., Griffoen, J., & Sudan, M. (1995). A reliable dissemination protocol for interactive collaborative applications. Proceedings of the Third ACM International Conference on Multimedia, (pp. 333-344). DOI: 10.1145/217279.215288

Raul H. Palacios (1,2), Maria Balseca (4), Victor Gallo (3), Nilo Andrade (5), Juan-Carlos Pisco (3), Fabricio Marrillo (2,3)

raulhp@ugr.es, maria.balseca@itsjba.edu.ec, vgallo@uteq.edu.ec, nilo.andrade@uleam.edu. ec, jpisco@uteq.edu.ec, fmarcillo@uteq.edu.ec

(1) Universidad Autonoma del Estado de Hidalgo, Escuela Superior de Huejutla, CP. 43000, Huejutla, Mexico.

(2) Centro de Investigacion en Tecnologias de la Informacion y Comunicacion, Granada, CP. 18014, Granada, Espana.

(3) Universidad Tecnica Estatal de Quevedo, Facultad Ciencias de la Ingenieria, CP. 120501, Quevedo, Ecuador.

(4) Instituto Tecnologico Juan Bautista Aguirre, Daule, CP. 090601, Guayas, Ecuador.

(5) Universidad Laica Eloy Alfaro de Manabi, Chone, CP. 130301, Manabi, Ecuador.

DOI: 10.17013/risti.30.62-77

Caption: Figura 1--Configuracion basica para envios multicast

Caption: Figura 2--Posibles puntos de congestion en transferencias multicast

Caption: Figura 3--Campos incluidos en el paquete broadcast con informacion de control

Caption: Figura 4--Diagrama de flujo basico del funcionamiento del mecanismo de control de congestion

Caption: Figura 5--Asignacion de Tcwnd segun calculo realizado en el algoritmo de control de congestion

Caption: Figura 6--Valores para [DELTA][T.sub.x]_[R.sub.x] respecto al ancho de banda de recepcion

Caption: Figura 7--Ancho de banda en receptor con diferentes tamanos de envio

Caption: Figura 8--Ancho de banda de 2 emisores y receptor para CWND = 3

Caption: Figura 9--Perdida de paquetes para CWND = 3

Caption: Figura 10--Ancho de banda de 2 emisores y receptor para CWND = 4

Caption: Figura 11--Perdida de paquetes para CWND = 4

Caption: Figura 12--Evaluacion de escrituras simultaneas en disco SSD
Tabla 1--Control de congestion implementado en los RMP.

Protocolo    Control de congestion    Segun TCP

RDCM         Window-based             BIC
NORM         Rate-based               TCP-Friendly
PGM          Window-based             TCP-Friendly
RMTP         Window-based             slow-start
             Window-based
TMTP         Rate-based               --
COPYRIGHT 2018 AISTI (Iberian Association for Information Systems and Technologies)
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2018 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Palacios, Raul H.; Balseca, Maria; Gallo, Victor; Andrade, Nilo; Pisco, Juan-Carlos; Marrillo, Fabri
Publication:RISTI (Revista Iberica de Sistemas e Tecnologias de Informacao)
Date:Dec 1, 2018
Words:4911
Previous Article:New challenges in IS: The increasing importance of cyber-physical processes/Novos desafios em SI: A crescente importancia dos processos ciber-fisicos.
Next Article:System to collect and make available data from potential roles in highways/Sistema para Coleta e Disponibilizacao de Dados de Potenciais Buracos em...
Topics:

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters