MIME-Version: 1.0 Content-Location: file:///C:/916BB24E/Congestion.htm Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" Algoritmo de Control de la Congestion

= Algoritmo de Control de la Congestion

 

Tomando e= n cuenta la asignación de recursos en forma anticipada, que se desechen los paquetes cuando no se puedan procesar, que se restrinjan el número de paquetes en la subred, utilizando el control de flujo para evitar la congestión y obstruir la entrada de datos cuando la subred este sobrecargada.


PREASIGNACIÓN DE TAMPONES Si se utilizan circuitos virtuales dentro = de la subred, es posible resolver por completo el problema de la congestión, de la manera siguiente. Cuando se establece un circuito virtual, el paquete de solicitud de llamada sigue su camino a través= de la subred, produciendo entradas en las tablas según avanza. En el momento en que llega a su destino, la ruta que deberá seguir todo el trafico subsiguiente ya se ha determinado, así como se han hecho entradas en las tablas de encaminamiento de todos los IMP intermedios. Normalmente, el paquete de solicitud de llamada no reserva ningún espacio de memoria en los IMP intermedios, sino solo ranuras en las tablas.= Sin embargo una sencilla modificación del algoritmo de establecimiento podría hacer que cada uno de los paquetes de solicitud de llamada reserve, también, uno o más tampones para datos. Si llaga un paquete de solicitud de llamada a un IMP y todos los tampones fueron reserv= ados con anticipación, se procederá a buscar otra ruta alternativa para el proceso, o bien, devolver una "señal de ocupado". = Aun cuando los tampones se reserven algunos de los circuitos que aspiran a ser circuitos virtuales pueden ser reencaminados o rechazados por falta de espa= cio el la tabla, reservar memorias no agrega ningún problema adicional a= los ya existentes. Al asignar permanentemente tampones a cada uno de los circui= tos virtuales en cada IMP, siempre habrá un lugar para almacenar cualqui= er paquete que llegue hasta que pueda ser reexpedido. Un tampón por circuito virtual por IMP es suficiente para circuito simplex, y uno por cada dirección es suficiente para circuitos duplex. Cuando llega un paque= te, el asentimiento no se devuelve al IMP transmisor, sino hasta que el paquete= se haya reexpedido. Si el protocolo IMP-IMP permite múltiples paquetes pendientes, cada IMP tendrá que dedicar una ventana completa de tamp= ones para cada circuito virtual, para poder eliminar por completo la posibilidad= de congestión. Cuando cada uno de los circuitos virtuales que pasan por= el IMP tiene suficiente espacio de tampones dedicados a él, la conmutación de paquetes llega a ser muy parecida a la conmutaci&oacu= te;n de circuitos. En los dos casos, al final hay un uso de recursos de recursos potencialmente ineficiente, por que los recursos que no llegan a ser utiliz= ados por la conexión a la que están asignados, sin embargo, no están disponibles para nadie más. Debido a que dedicar un conjunto completo de tampones a un circuito virtual inactivo es extraordinariamente costoso, algunas subredes lo utilizan solo en aquellos casos en donde es primordial tener un retardo muy pequeño y un gran ancho de banda. Si el tampón permaneciera inactivo demasiado tiempo,= se llegaría liberar, para ser adquirido de nuevo, cuando llegara el siguiente paquete, así los paquetes tendrán que reexpedirse s= in tener tampones dedicados a ese momento, sino hasta que la cadena de tampones pueda establecerse de nuevo.


DESCARTE DE PAQUETES El segundo mecanismo de control de la congestió= n en lugar de reservar todos los tampones anticipadamente no se reserva nada absolutamente por adelantado. Si llega un paquete y no existe lugar disponi= ble para colocarlo, el IMP simplemente lo descarta, el problema de la congestión se resuelve simplemente al descartar los paquetes a volun= tad. Si la subred ofrece un servicio de circuito virtual, en algún lugar = se deberá una copia del paquete para que pueda transmitirse despu&eacut= e;s. Una posibilidad consiste en hacer que el IMP que transmitió el paque= te descartado espere un tiempo y retransmita el paquete hasta que sea recibido. Otra posibilidad es que el IMP emisor renuncie, después de realizar varios intentos. Resultaría bastante tonto ignorar la llegada de un = paquete que contenga un asentimiento procedente de un IMP vecino. Este asentimiento= le permitirá al IMP abandonar un paquete ya recibido y liberar as&iacut= e; un tampón. Sin embargo, si el IMP no cuenta con tampones disponibles= no podrá recibir ningún paquete para ver si contiene asentimient= os. La solución consiste en reservar permanentemente un tampón por línea de entrada con objeto de permitir que se inspeccione todos los paquetes que llegan. Para el IMP resulta bastante justificable examinar el paquete recién llegado, el portador de buenas noticias puede ser recompensado y usar el tampón que desocupo como nueva memoria de entrada. La congestión debe ser evitada, una sola línea de sa= lida acaparar en un IMP todos los tampones disponibles, dado que asigna sencillamente bajo la regla del primero que llega es el primero en ser atendido. Aun cuando dos líneas de salida estén inactivas, cualquier paquete de entrada destinado a alguna de ellas, deberá descartarse debido a que no hay tampones disponibles. Esto es un desperdici= o. Una idea consiste en limitar el número de tampones que puedan vincul= arse a cualquier cola de salida. Después de todo, esa línea de sal= ida ya esta operando a su máxima capacidad. El hecho de tener 7 paquetes= en una cola de espera en lugar de 4 no bombeara bits a una velocidad mayor, si= no que más bien permitirá que el trafico a otras líneas se reexpida inmediatamente, con la posibilidad de duplicar o triplicar la tasa= de la salida del IMP. De cualquier modo, el paquete desechado se retransmitir&= aacute; antes de que la cola de espera se vacié, así que su rechazo inicial ni siquiera se notara. Aunque descartar paquetes sea sencillo tiene algunas desventajas; unas de las mas importantes es el ancho de banda que se necesita para los duplicados, si este es muy corto, los duplicados podrían ser generados cuando no se necesiten, empeorando todav&iacut= e;a mas la congestión. Si por otra parte es muy largo, el retardo sufrirá las consecuencias.


CONTROL ISARÍTMICO DE LA CONGESTIÓN La congestión tiene lugar cuando hay demasiados paquetes en la subred. Un planteamiento directo para controlarlo consistirá en limitar el numero de paquetes present= es en la subred. Un método llamado, isarítmico, debido a que mantiene constante el numero de paquetes, existen permisos, que circulan de= ntro de la subred, siempre que un IMP desee transmitir un paquete recién entregado apenas por su hostal, primero deberá capturar un permiso y después destruirlo. Cuando finalmente, el IMP destinatario saca el paquete de la subred, regenera el permiso. Estas reglas sencillas asegura q= ue el numero de paquetes de la subred nunca exceda el número de permisos que inicialmente están presentes. Este método tiene algunos problemas. Primero, aunque garantiza que la subred como un todo nunca llega= ra a congestionarse, no garantiza que un IMP determinado súbitamente queda abrumado por paquetes. Segundo, como distribuir permisos esta legos de ser obvio. Para evitar que un nuevo paquete generado sufra de un gran retardo mientras el IMP local trata de obtener un permiso, los primeros deber&aacut= e;n estar uniformemente distribuidos, de tal manera que cualquier IMP tenga algunos. Por otra parte, para permitir la transferencia de archivos con un = gran ancho de banda, no es deseable que el IMP transmisor tenga que andar buscan= do por todas partes suficientes permisos. Seria mucho mas conveniente que todos estuvieran centralizados, de tal forma que la petición de una cantid= ad considerable se pudiera cumplir con mayor rapidez. Tercero si por alguna razón los permisos llegan a ser destruidos la capacidad de transport= e de la red se reducirá para siempre. No hay ninguna manera sencilla de determinar cuantos permisos existen todavía, mientras la red este funcionando.


CONTROL DE FLUJO Algunas redes han intentado utilizar mecanismos de control= de flujo para eliminar la congestión. Aunque la capa de transporte puede lleg= ar a utilizar esquemas de control de flujo para impedir que un hostal sature a o= tro y, además, los esquemas de control de flujo puedan utilizarse para evitar que un IMP sature a sus vecinos, es extremadamente difícil controlar la cantidad total de trafico en la red, si los hostales se ven forzados a detener la transmisión debido a las estrictas reglas de control de flujo, la subred llegara a estar suficientemente cargada. El con= trol de flujo no puede llegar a resolver fácilmente los problemas de congestión, el trafico de un ordenador es a ráfagas. Cuando se desea explorar un archivo muy grande. El pico de tráfico potencial es bastante mayor que el valor promedio. Cualquier esquema de control de flujo, que se ajuste para restringir al usuario al valor medio, dará en definitiva un mal servicio cuando este solicite un trafico a ráfagas= . Si el límite del control de flujo se establece con un valor suficientem= ente alto, para permitir que el pico del trafico se logre, tendrá poco va= lor como control de congestión. Cuando el control de flujo se utiliza co= mo intento para acabar con la congestión, se puede aplicar al trafico e= ntre pares de:

1. procesos de usuario
2. Hostales, sin tomar en cuenta el numero de circuitos virtuales abiertos.=
3. IMP de origen, sin considerar a los hostales.
Además se puede restringir el número de circuitos virtuales abiertos.