MIME-Version: 1.0 Content-Location: file:///C:/916BB24E/Congestion.htm Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
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.