Hola:
No logro captar la situación, y tampoco entiendo lo que explica el solucionario. ¿Podrían ilustrar o describir mejor el escenario?
Gracias.
Hola:
No logro captar la situación, y tampoco entiendo lo que explica el solucionario. ¿Podrían ilustrar o describir mejor el escenario?
Gracias.
Buenas,
el escenario es el mismo que el ej 12, pero ahora tenés que considerar la existencia de un buffer del lado del emisor. Luego se intenta relacionar el tamaño de este buffer con la velocidad del enlace y el RTT
Saludos
Hola Leonardo:
Gracias por responder. Pero sigo sin comprender: si es el mismo escenario del problema 12, el tamaño de la ventana de congestión seguirá variando en forma de diente de sierra desde W/2 hasta W (evitación de la congestión) para caer nuevamente a W/2 (recuperación rápida) y así periódicamente, ¿correcto? Entonces, ¿cómo puede usar un buffer el emisor para mantener ocupado el canal, si no puede transmitir en cada RTT más que lo autorizado por la ventana de congestión?
Hola,
ni se si entiendo del todo tu planteo. En esta parte se plantea la existencia de un buffer en el emisor, dado que los paquetes se descartarán si la velocidad máxima de envío excede la capacidad del enlace.
En el escenario del 12, el emisor va a tener un tamaño máximo de ventana (restringido por la capacidad del enlace que mencioné). Además, el buffer de recepción del receptor es mucho más grande que la ventana de congestión, por lo que la limitante es el tamaño máximo de la ventana de congestión.
En ese caso, si tomas como W el tamaño máximo de la ventana, esta irá variando entre W y W/2 como mencionas, pero entre "arranque lento" y "evitación de la congestión", dado que una vez que lleguemos al tamaño máximo sin contar con un buffer para paliar la capacidad del enlace, van a existir pérdidas.
Espero haber explicado un poco más el escenario, sino volvé a preguntar.
Saludos,
Leonardo.
Hola Leonardo, y gracias por tu paciencia. Voy a tratar de expresar mejor mi duda
En el escenario del problema 12, sin buffer, la tasa del emisor está regulada por la VC de acuerdo a la gráfica:
Pero cómo sería la gráfica en el escenario del problema 13, con la presencia del buffer?
1) Horizonal, constante con valor W? (eso es lo que me suena a tener ocupado permanentemente el canal)
2) Igual a la anterior, con diente de sierra, pero "disparando" el buffer al llegar a W para evitar las pérdidas? O sea, el buffer se usaría en el ciclo crítico para rellenar el canal?
3) Ninguna de las anteriores?
Buenas,
el algoritmo que se utiliza es el mismo, y el tamaño de la ventana también, por lo tanto el diagrama de cómo varía la ventana, es el de la imagen.
Acá nuevamente si el tamaño de la ventana alcanza W, se producirá una pérdida y el remitente reducirá el tamaño de su ventana de congestión a la mitad. En este punto esperará los ACK para los W/2 paquetes, antes de comenzar a enviar segmentos de datos nuevamente (suponiendo que envía "en rondas"). Para asegurar de que el enlace siempre esté ocupado enviando datos, hay que dejar el enlace ocupado enviando datos en el intervalo de tiempo en el que el emisor espera los ACK para estos los W/2 paquetes.
Hola nuevamente:
La parte que más me confunde del solucionario es la siguiente:
Let Tp denote the one-way propagation delay between the sender and the receiver. When the window size reaches the minimum W/2 and the buffer is empty, we need to make sure the link is also busy sending data. Thus, we must have W/2/(2Tp)>=C, thus, W/2>=C*2Tp.
Tampoco me queda muy claro cuándo y cómo actúa el buffer del emisor. Si es sólo en el RTT en que la ventana de congestión cae de W a W/2 o si es en cada RTT. Y si el buffer transmite como un "demonio" por su cuenta para ocupar el canal porque se supone que el emisor no debería transmitir mientras espera esos W/2 ACKs
Un diagramita sería de mucha ayuda...