Solución a Problemas

Computer Networking: A Top-Down Approach, 7th Edition

Realizado por:
Maguana July,
Ordoñez Luis,
Otavalo José Andrés,
Tobar Micaela y
Villegas Soledad

PROBLEMAS CAPITULO 3
1.Suponga que el cliente A inicia una sesión Telnet con el servidor S. Aproximadamente en el
mismo instante, el cliente B también inicia una sesión Telnet con el servidor S. Proporcione los
posibles números de puerto de origen y de destino para:

a) Los segmentos enviados de A a S.

b) Los segmentos enviados de B a S.
c) Los segmentos enviados de S a A.
d) Los segmentos enviados de S a B.
e) Si A y B son hosts diferentes, ¿es posible que el número de puerto de origen en los
segmentos que van de A a S sea el mismo que en los segmentos que van de B a S?
f) ¿Qué ocurre si A y B son el mismo host?
Solución:

a)

Puerto Origen Puerto Destino

2555 50

b)

Puerto Origen Puerto Destino

415 50

c)

Puerto Origen Puerto Destino

50 2555

d)

Puerto Origen Puerto Destino

50 415
e)
Si es posible
f)
No puede ser el mismo host.
2.Considere la Figura 3.5. ¿Cuáles son los valores de los puertos de origen y de destino en los
segmentos que fluyen desde el servidor de vuelta a los procesos cliente? ¿Cuáles son las
direcciones IP de los datagramas de la capa de red que transportan los segmentos de la capa de
transporte?
Solución:

Supongamos que las direcciones IP de los hosts A, B y C son a, b, c, (a, b, c son distintos.)
A: Puerto de origen es 80, la dirección IP de origen es b, puerto destino es 26145, dirección IP destino
es a:

Puerto de Origen Puerto de Destino

2555 50

C proceso izquierdo: Puerto de origen es 80, la dirección IP de origen es b, puerto destino es 7532, la
dirección IP destino es c.
C, proceso derecho: Puerto de origen es 80, la dirección IP de origen es b, puerto destino es 26145,
dirección IP destino es c.

3.UDP y TCP utilizan el complemento a 1 para calcular sus sumas de comprobación. Suponga
que tiene los tres bytes de 8 bits siguientes: 01010011, 01100110, 01110100. ¿Cuál es el
complemento a 1 de la suma de estos bytes? (Observe que aunque UDP y TCP emplean
palabras de 16 bits para calcular la suma de comprobación, en este problema le pedimos que
considere sumas de 8 bits). Explique cómo funciona. ¿Por qué UDP utiliza el complemento a 1
de la suma; es decir, por qué no simplemente emplea la suma? Con el esquema del complemento
a 1, ¿cómo detecta el receptor los errores? ¿Es posible que un error de un solo bit no sea
detectado? ¿Qué ocurre si hay 2 bits erróneos?
Solución:

Encontraremos el complemento a 1 de la suma de los bits dados:

01010011
Suma 1 01010100
10100111
01100110
Suma 2 01110100
00011011
00011011
Complemento 11100100
11111111
Tanto UDP como TCP utilizan palabras de 16 bits para calcular la suma de comprobación, para este
problema en particular utilizaremos 8 bits de los que se nos da y los demás se agregaran ceros, asi el
complemento se suma con el contenido de la cabecera de datos del segmento TCP y agrupamos en
intervalos de 8 bits de manera que:

Bits 0 - 15 Bits 16 -31

Puerto Origen Puerto Destino
Longitud de Mensaje Suma de Verficación
Datos

Asi para que el complemento a 1 de la suma pueda alcanzar los bits requeridos por la cabecera UDP y
TCP debe quedar como:

0101001100000000
0101010000000000
1010011100000000
0110011000000000
0111010000000000
0001101100000000
0001101100000000
1110010111111111
1111111111111111

¿Por qué UDP utiliza el complemento A1 de la suma; ¿es decir, por qué no simplemente emplea la
suma?
Se usa la suma en complemento a uno porque el acarreo final de ese método puede ser calculado en
cualquier múltiplo de su tamaño (16-bit, 32-bit, 64-bit...)y el resultado una vez plegado será el mismo.
El receptor recalcula la suma de comprobación sobre las cabeceras y datos recibidos
¿Con el esquema del complemento A1, ¿cómo detecta el receptor los errores?
El complemento es A1 es usado para que el receptor no tenga que poner ceros en el campo de la suma
de comprobación de la cabecera antes de hacer los cálculos, salvando en algún lugar el valor de la suma
de verificación recibida; en vez de eso, el receptor simplemente calcula la suma en complemento a uno
con la suma de verificación incluida, y el resultado debe ser todo igual a 1. Si es así el segmento ha
llegado intacto y sin errores.
¿Es posible que un error de un solo bit no sea detectado?
La suma de comprobación es bastante débil. En niveles de enlace con una alta probabilidad de error de
bit quizá requiera una capacidad adicional de corrección/detección de errores de enlace, pero está
parcialmente compensada por el extendido uso de un CRC en el nivel de enlace. Sin embargo, esto no
significa que una suma de comprobación de 16 bits sea eficiente, inspecciones sobre el tráfico de
Internet han mostrado que son comunes los errores de software y hardware que introducen errores en
los paquetes protegidos con un CRC, y que la suma de comprobación de 16 bits detecta la mayoría de
estos errores simples.
¿Qué ocurre si hay 2 bits erróneos?
Si existen errores de bits en la transmisión, el segmento que se transfiere a través del enlace tendrá
errores, dado a que en UDP no están garantizadas la fiabilidad de enlace a enlace ni la detección de
errores durante el almacenamiento en memoria.

4. a. Suponga que tiene los 2 bytes siguientes: 01011100 y 01100101. ¿Cuál es el complemento
a 1 de la suma de estos 2 bytes?
b. Suponga que tiene los 2 bytes siguientes: 11011010 y 01100101. ¿Cuál es el complemento
a 1 de la suma de estos 2 bytes?
c. Para los bytes del apartado (a), proporcione un ejemplo en el que un bit cambie de valor en
cada uno de los 2 bytes y aun así el complemento a 1 no varíe.
Solución:

a)
0 1 0 1 1 1 0 0
+ 0 1 1 0 0 1 0 1
1 1 0 0 0 0 0 1

Por lo tanto, el complemento a1: 00111110

b)
1 1 0 1 1 0 1 0
+ 0 1 1 0 0 1 0 1
0 0 1 1 1 1 1 1

Por lo tanto, el complemento a1: 11000000

c)
Para el byte 1: 01010100
Para el byte 2: 01101101
5. Suponga que el receptor UDP calcula la suma de comprobación de Internet para el segmento
UDP recibido y comprueba que se corresponde con el valor almacenado en el campo de suma
de comprobación. ¿Puede el receptor estar completamente seguro de que no hay ningún bit
erróneo? Explique su respuesta.
Solución:

No, el receptor no puede estar absolutamente seguro de que no se hayan producido errores de bits.
Esto se debe a la forma en que se calcula la suma de comprobación del paquete. Si los bits
correspondientes que se suman de dos palabras de 16 bits en el paquete fueran 0 y 1, incluso si se
volteaban a 1 y 0 respectivamente, la suma sigue siendo la misma. Por lo tanto, el complemento de 1
que calcula el receptor también será el mismo. Esto significa que la suma de comprobación verificará
incluso si hubo un error de transmisión.
6. Recuerde el motivo de corregir el protocolo rdt2.1. Demuestre que el receptor mostrado en
la Figura 3.57 y el emisor mostrado en la Figura 3.11 pueden llegar a entrar en un estado de
bloqueo tal que cada uno de ellos esté esperando a que se produzca un suceso que no ocurrirá
nunca.
Solución:

Suponga que el remitente está en el estado "Espere la llamada 1 desde arriba" y el receptor (el
receptor que se muestra en el problema de la tarea) está en el estado "Espere 1 desde abajo". El
remitente envía un paquete con el número de secuencia 1 y pasa a "Esperar ACK o NAK 1",
esperando un ACK o NAK. Supongamos que ahora el receptor recibe el paquete con el número de
secuencia 1 correctamente, envía un ACK y pasa al estado "Espere 0 desde abajo", esperando un
paquete de datos con el número de secuencia 0. Sin embargo, el ACK está dañado.
Cuando el remitente rdt2.1 recibe el ACK dañado, reenvía el paquete con el número de secuencia 1,
Sin embargo, el receptor está esperando un paquete con el número de secuencia 0 y (como se muestra
en el problema del trabajo a domicilio) siempre envía un NAK cuando no recibe un paquete con el
número de secuencia 0. Por lo tanto, el remitente siempre enviará un paquete con el número de
secuencia 1 y el receptor siempre estará Hawking ese paquete. Tampoco progresará desde ese estado.
7.En el protocolo rdt3.0, los paquetes ACK que fluyen del receptor al emisor no tienen números
de secuencia (aunque tienen un campo ACK que contiene el número de secuencia del paquete que
están reconociendo). ¿Por qué estos paquetes ACK no requieren números de secuencia?
Solución:

Se sabe que el remitente necesita números de secuencia para que el receptor pueda saber si un paquete
de datos es un duplicado de un paquete de datos ya recibido. En el caso de los ACK, el remitente no
necesita esta información (es decir, un número de secuencia en un ACK) para detectar un ACK
duplicado. Un ACK duplicado es obvio para el receptor rdt3.0, ya que cuando recibió el ACK original
pasó al siguiente estado. El ACK duplicado no es el ACK que necesita el remitente y, por lo tanto, el
remitente rdt3.0 lo ignora.
8.Dibuje la máquina de estados finitos correspondiente al lado receptor del protocolo rdt3.0.
Solución:

El lado del remitente del protocolo rdt3.0 difiere del lado del remitente del protocolo 2.2 en que se han
agregado tiempos de espera. La introducción de tiempos de espera agrega la posibilidad de paquetes
duplicados en el flujo de datos de remitente a receptor. Sin embargo, el receptor en el protocolo rdt.2.2
ya puede manejar paquetes duplicados. Los duplicados del lado del receptor en rdt 2.2 surgirían si el
receptor envía un ACK que se perdió y el remitente luego retransmitió los datos antiguos. Por tanto, el
receptor del protocolo rdt2.2 también funcionará como receptor del protocolo rdt 3.0.
9.Dibuje un esquema que muestre la operación del protocolo rdt3.0 cuando los paquetes de datos
y los paquetes de reconocimiento están corrompidos.
Solución:

10. Sea un canal que puede perder paquetes, pero del que se conoce su retardo máximo. Modifique
el protocolo rdt2.1 para incluir los fines de temporización y las retransmisiones del emisor.
Argumente de manera informal por qué su protocolo puede comunicarse correctamente a través
de este canal.
Solución:

Vamos a agregar un temporizador cuyo valor es mayor que el retardo de propagación de ida y vuelta
conocido. Agregamos un evento de tiempo de espera a ACK o NAK0 y esperar ACK o NAK1 estados.
Si se produce el evento de tiempo de espera, se retransmite el paquete transmitido más recientemente.
Veamos por qué este protocolo seguirá funcionando con el receptor rdt2.1
Suponga que el tiempo de espera se debe a la pérdida de un paquete de datos, es decir, un paquete en el
canal emisor-receptor. En este caso, el receptor nunca recibió la anterior transmisión y, desde el punto
de vista del receptor, si la retransmisión de tiempo de espera es recibido, se ve exactamente igual que
si la transmisión original estuviera siendo recibida.
Supongamos ahora que se pierde un ACK. El receptor eventualmente retransmitirá el paquete en un
tiempo de espera. Pero una retransmisión es exactamente la misma acción que si un ACK está
distorsionado. Por tanto, la reacción del remitente es la misma con una pérdida que con una ACK
confuso. El receptor rdt 2.1 ya puede manejar el caso de un ACK confuso.
11. Considere el receptor rdt2.2 mostrado en la Figura 3.14 y la creación de un paquete nuevo en
la transición a sí mismo (esto es, la transición del estado de vuelta hacia sí mismo) en los estados
Esperar 0 de abajo y Esperar 1 de abajo: pqtenv=crear_pqt(ACK,1,sumacomprobacion) y
pqtenv=crear_pqt(ACK,0,sumacomprobacion). ¿Funcionaría correctamente el protocolo si se
eliminara esta acción de la transición al mismo estado en el estado Esperar 1 de abajo? Justifique
su respuesta. ¿Qué ocurrirá si se elimina este suceso de la transición del estado Esperar 0 de abajo
a sí mismo? [Sugerencia: en este último caso, considere lo que ocurriría si el primer paquete que
va del emisor al receptor estuviera corrompido.]
Solución:

Si se eliminara el envío de este mensaje, los lados emisor y receptor punto muerto, esperando un evento
que nunca ocurriría. Aquí hay un escenario:
El remitente envía pkt0, ingresa el "Wait for ACK0 state" y espera un paquete de regreso desde el
receptor. El receptor está en el estado "Espere 0 desde abajo" y recibe un paquete dañado del remitente.
Suponga que no devuelve nada y simplemente vuelve a ingresar al "Espere 0 desde abajo".
12. El lado del emisor de rdt3.0 simplemente ignora (es decir, no realiza ninguna acción) todos los
paquetes recibidos que contienen un error o que presentan un valor erróneo en el campo número
de reconocimiento (acknum) de un paquete de reconocimiento. Suponga que, en tales
circunstancias, rdt3.0 simplemente retransmite el paquete de datos actual. ¿Funcionaría en estas
condiciones el protocolo? (Sugerencia: piense en lo que ocurriría si solo hubiera errores de bit;
no se producen pérdidas de paquetes, pero sí pueden ocurrir sucesos de fin prematuro de la
temporización. Considere cuántas veces se envía el paquete n, cuando n tiende a infinito.)
Solución:
El protocolo aún funcionaría, ya que una retransmisión sería lo que sucedería si el paquete recibido con
errores en realidad se ha perdido y desde el punto de vista del receptor, nunca se sabe cuál de estos
eventos ocurrirá, si es que ocurrirá alguno. Para llegar al tema más sutil detrás de esta pregunta, uno
tiene que permitir tiempos de espera que se produzcan. En este caso, si cada copia adicional del paquete
es ACKED y cada recibido un ACK adicional hace que se envíe otra copia adicional del paquete actual,
el número de veces paquete n se envía aumentará sin límite como n se acerca al infinito.

13. Considere el protocolo rdt3.0. Dibuje un diagrama que muestre que si la conexión de red entre
el emisor y el receptor puede reordenar los mensajes (es decir, que dos mensajes que se propagan
por el medio físico existente entre el emisor y el receptor pueden ser reordenados), entonces el
protocolo de bit alternante no funcionará correctamente (asegúrese de identificar claramente el
sentido en el que no funcionará correctamente). En el diagrama debe colocar el emisor a la
izquierda y el receptor a la derecha, con el eje de tiempos en la parte inferior de la página y deberá
mostrar el intercambio de los mensajes de datos (D) y de reconocimiento (A). No olvide indicar el
número de secuencia asociado con cualquier segmento de datos o de reconocimiento.
Para enviar los paquetes se utilizó la siguiente nomenclatura M0 y M1, los cuales se están
enviando entre el receptor y emisor.

Solución:

Fue aceptado la versión antigua de M0

14. Considere un protocolo de transferencia de datos fiable que solo utiliza paquetes de
reconocimiento negativo. Imagine que el emisor envía datos con muy poca frecuencia. ¿Sería
preferible un protocolo con solo emplea paquetes NAK a uno que utilice paquetes ACK? ¿Por
qué? Suponga ahora que el emisor tiene muchos datos que transmitir y que la conexión terminal
a terminal experimenta muy pocas pérdidas. En este segundo caso, ¿sería preferible un protocolo
que solo emplee paquetes NAK a otro que utilice paquetes ACK? ¿Por qué?

Solución:

En el protocolo NAK, en el receptor solo se puede detectar la pérdida del paquete x cuando se recibe el
paquete x + 1. Es posible que los receptores reciben x-1 y luego x + 1, sólo cuando se recibe x + 1, el
receptor se da cuenta de que se perdió x. Si hay un retraso largo entre la transmisión de x y la transmisión
de x + 1, entonces pasará mucho tiempo hasta que se pueda recuperar x, bajo un protocolo solo NAK.

Por otra parte, si los datos se envían con frecuencia, la recuperación con un esquema solo NAK podría
ocurrir rápidamente. También, si los errores son poco frecuentes, los NAK solo se envían
ocasionalmente es decir cuando es necesario y nunca se envían ACK: una reducción significativa en la
retroalimentación en el caso de solo NAK sobre el caso de solo ACK.

15. Considere el ejemplo mostrado en la Figura 3.17. ¿Cuál tiene que ser el tamaño de la ventana
para que la tasa de utilización del canal sea mayor del 98 por ciento? Suponga que el tamaño de
un paquete es de 1.500 bytes, incluyendo tanto los campos de cabecera como los datos.
Se necesitan 0,012 milisegundos para enviar un paquete

Solución:

1500 ∗ 8
𝑡= = 12[𝜇𝑠]
109
Para que el remitente esté ocupado el 98 por ciento del tiempo, debemos tener
0.012[𝑛]
𝑢𝑡𝑖𝑙 = 0.98 =
30.012
O n aproximadamente 2451 paquetes.

16. Suponga que una aplicación utiliza el protocolo rdt 3.0 como su protocolo de la capa de
transporte. Como el protocolo de parada y espera tiene una tasa de utilización del canal muy baja
(como se ha demostrado en el ejemplo de conexión que atraviesa el país de costa a costa), los
diseñadores de esta aplicación permiten al receptor devolver una serie (más de dos) de ACK 0 y
ACK 1 alternantes incluso si los correspondientes datos no han llegado al receptor.
¿Debería este diseño de aplicación aumentar la tasa de utilización del canal? ¿Por qué? ¿Existe
algún problema potencial con esta técnica? Explique su respuesta.

Solución:

Sí un paquete experimenta un retardo particularmente grande, el emisor puede retransmitirlo incluso

aunque ni el paquete de datos ni su correspondiente ACK se hayan perdido. Esto introduce la posibilidad
de que existan paquetes de datos duplicados en el canal emisor-receptor, pero dispone de la
funcionalidad de los números de secuencia para afrontar la existencia de paquetes duplicados. Siendo
fiable el aumentar la tasa de utilización del canal.
El problema potencial es que el protocolo debería recuperarse de la pérdida de paquetes tan pronto como
fuera posible; pero si espera un tiempo igual al retardo en el caso peor, eso significa una larga espera
hasta iniciar el mecanismo de recuperación de errores.
17. Suponga que tenemos dos entidades de red, A y B, que están conectadas mediante un canal
bidireccional perfecto (es decir, cualquier mensaje enviado será recibido correctamente; el canal
no corromperá, no perderá y no reordenará los paquetes). A y B se entregan mensajes de datos
entre sí de manera alternante: en primer lugar, A debe entregar un mensaje a B, después B
entrega un mensaje a A; a continuación, A entregará un mensaje a B, y así sucesivamente. Si una
entidad se encuentra en un estado en el que no debería enviar un mensaje al otro lado y se produce
un suceso como rdt_enviar(datos) procedente de arriba puede simplemente ignorarlo con una
llamada a rdt_inhabilitar_enviar(datos), que informa a la capa superior de que actualmente no
es posible enviar datos. [Nota: esta simplificación se hace para no tener que preocuparse por el
almacenamiento de datos en buffer].
Diseñe una especificación de la máquina de estados finitos (FSM) para este protocolo (una
máquina FSM para A y una máquina FSM para B). Fíjese en que en este caso no tiene que
preocuparse por el mecanismo de fiabilidad; el punto clave de esta cuestión es crear la
especificación de una máquina FSM que refleje el comportamiento sincronizado de las dos
entidades. Deberá emplear los siguientes sucesos y acciones, los cuales tienen el mismo significado
que en el protocolo rdt1.0 de la Figura 3.9: rdt_enviar(datos), pqt=crear_pqt(datos),
udt_enviar(pqt), rdt_recibir(pqt), extraer (pqt,datos), entregar_datos(datos). Asegúrese de que el
protocolo refleja la alternancia estricta de envío entre A y B. Asegúrese también de indicar los
estados iniciales para A y B en sus descripciones de la FSM.

Solución:

18. En el protocolo SR genérico que hemos estudiado en la Sección 3.4.4, el emisor transmite un
mensaje tan pronto como está disponible (si se encuentra dentro de la ventana) sin esperar a
recibir un paquete de reconocimiento. Suponga ahora que deseamos disponer de un protocolo SR
que envíe mensajes de dos en dos. Es decir, el emisor enviará una pareja de mensajes y enviará
la siguiente pareja de mensajes solo cuando sepa que los dos mensajes de la primera pareja se
han recibido correctamente. Suponga que el canal puede perder mensajes, pero no corromperlos
ni tampoco reordenarlos.
Diseñe un protocolo de control de errores para un servicio de transferencia de mensajes fiable y
unidireccional. Proporcione una descripción de las máquinas de estados finitos del emisor y del
receptor. Describa el formato de los paquetes intercambiados por el emisor y el receptor, y
viceversa. Si utiliza alguna llamada a procedimiento distinta de las empleadas en la Sección 3.4
(por ejemplo, udt_enviar(), iniciar_temporizador(), rdt_recibir(), etc.), defina claramente las
acciones que realizan. Proporcione un ejemplo (una gráfica temporal del emisor y del receptor)
que muestre cómo este protocolo se recupera de la pérdida de Paquete

Solución:
Pqt# enviado: paquete número # enviado desde el emisor.
IN temp pqt#: inicia el temporizador del paquete número #.
OUT temp pqt#: el temporizador del paquete número # termina y retransmite el paquete.
ACK 1, ACK 2 enviado: se envía el ACK de los dos paquetes recibidos.
ACK 1, ACK 2 recibido: se recibe el ACK del transmisor.

19. Considere un escenario en el que el host A desea enviar simultáneamente paquetes a los hosts
B y C. El host A está conectado a B y C a través de un canal de multidifusión (broadcast) (un
paquete enviado por A es transportado por el canal tanto a B como a C). Suponga que el canal de
multidifusión que conecta A, B y C puede perder y corromper de manera independiente los
paquetes (es decir, puede ocurrir, por ejemplo, que un paquete enviado desde A llegue
correctamente a B, pero no a C). Diseñe un protocolo de control de errores similar a un protocolo
de parada y espera que permita transferir paquetes de forma fiable de A a B y C, de manera que
A no obtendrá nuevos datos de la capa superior hasta que sepa que tanto B como C han recibido
correctamente el paquete actual. Proporcione las descripciones de las máquinas de estados finitos
de A y C. (Sugerencia: la FSM de B será prácticamente la misma que la de C.) Proporcione
también una descripción del formato o formatos de paquete utilizados.
Solución:

Este problema es una variación del protocolo simple de detener y esperar (rdt3.0). Porque el canal puede
perder mensajes y porque el remitente puede reenviar un mensaje que uno de los receptores ya ha
recibido (ya sea por un tiempo de espera prematuro o porque el otro receptor aún tiene que recibir los
datos correctamente), se necesitan números de secuencia. Como en rdt3.0, un número de secuencia de
0 bits será suficiente aquí.
El FSM emisor y receptor se muestran en la figura a continuación. En este problema, el estado del
emisor indica si el remitente ha recibido un ACK de B (únicamente), de C (únicamente) o de ni C ni B.
El estado del receptor indica qué número de secuencia es el receptor esperando
20. Considere un escenario en el que el host A y el host B desean enviar mensajes al host C. Los
hosts A y C están conectados mediante un canal que puede perder y corromper (pero no
reordenar) los mensajes. Los hosts B y C están conectados a través de otro canal (independiente
del canal que conecta a A y C) que tiene las mismas propiedades. La capa de transporte del host
C tiene que alternar la entrega de los mensajes que A y B tienen que pasar a la capa superior (es
decir, primero entrega los datos de un paquete de A y luego los datos de un paquete de B, y así
sucesivamente). Diseñe un protocolo de control de errores de tipo parada y espera para transferir
de forma fiable los paquetes de A y B a C, con una entrega alternante en el host C, como hemos
descrito anteriormente. Proporcione las descripciones de las FSM de A y C. (Sugerencia: la FSM
de B será prácticamente la misma que la de A.) Proporcione también una descripción del formato
o formatos de paquete utilizados.
Solución:
21. Suponga que tenemos dos entidades de red, A y B. B tiene que enviar a A un conjunto de
mensajes de datos, cumpliendo los siguientes convenios. Cuando A recibe una solicitud de la capa
superior para obtener el siguiente mensaje de datos (D) de B, A tiene que enviar un mensaje de
solicitud (R) a B a través del canal que va de A a B. Solo cuando B recibe un mensaje R puede
devolver un mensaje de datos (D) a A a través del canal de B a A. A tiene que entregar
exactamente una copia de cada mensaje D a la capa superior. Los mensajes R se pueden perder
(pero no corromper) en el canal de A a B; los mensajes D, una vez enviados, siempre son
correctamente entregados. El retardo a lo largo de ambos canales es desconocido y variable.
Diseñe (proporcione una descripción de la FSM de) un protocolo que incorpore los mecanismos
apropiados para compensar las pérdidas del canal de A a B e implemente el paso de los mensajes
a la capa superior de la entidad A, como se ha explicado anteriormente. Utilice solo aquellos
mecanismos que sean absolutamente necesarios.
Solución:

Debido a que el canal A a B puede perder mensajes de solicitud, A necesitará un tiempo de espera y
retransmitir sus mensajes de solicitud (para poder recuperarse de la pérdida). Debido a que los retrasos
del canal son variables y desconocidos, es posible que A envíe solicitudes duplicadas (es decir, reenviar
un mensaje de solicitud que ya ha sido recibido por B). Para poder detectar mensajes de solicitud
duplicados, el protocolo utilizará números de secuencia. Una secuencia de 1 bit número será suficiente
para un tipo de protocolo de solicitud / respuesta de detener y esperar.
A (el solicitante) tiene 4 estados:
  "Espere la Solicitud 0 desde la superior". Aquí el solicitante está esperando una llamada desde
la capa superior para solicitar una unidad de datos. Cuando recibe una solicitud de la capa
superior, envía un mensaje de solicitud, R0, a B, inicia un temporizador y hace una transición
al estado "Esperar D0". Cuando se encuentra en el estado "Esperar solicitud 0 desde la capa
superior", A ignora cualquier cosa que reciba de B.

 “Esperar D0”. Aquí el solicitante está esperando un mensaje de datos D0 de B. Un temporizador

siempre está funcionando en este estado. Si el temporizador expira, A envía otro mensaje R0,
reinicia el temporizador y permanece en este estado. Si se recibe un mensaje D0 de B, A detiene
el tiempo y pasa al estado "Esperar solicitud 1 desde la capa superior". Si A recibe un mensaje
de datos D1 mientras se encuentra en este estado, se ignora.

 "Esperar la Solicitud 1 de arriba". Aquí, el solicitante está nuevamente esperando una llamada
desde arriba para solicitar una unidad de datos. Cuando recibe una solicitud de arriba, envía un
mensaje de solicitud, R1, a B, inicia un temporizador y hace una transición al estado “Espere
D1”. Cuando se encuentra en el estado "Esperar solicitud 1 de arriba", A ignora todo lo que
recibe de B.

 “Espere D1”. Aquí el solicitante está esperando un mensaje de datos D1 de B. A el temporizador

siempre está funcionando en este estado. Si el temporizador expira, A envía otro R1 mensaje,
reinicia el temporizador y permanece en este estado. Si se recibe un mensaje D1 de B, A detiene
el temporizador y pasa al estado "Esperar solicitud 0 desde la capa superior". Si A recibe un
mensaje de datos D0 mientras se encuentra en este estado, se ignora.

El proveedor de datos (B) tiene solo dos estados:

 "Envía D0". En este estado, B continúa respondiendo a los mensajes R0 recibidos enviando D0
y luego permanece en este estado. Si B recibe un mensaje R1, entonces sabe que su mensaje
D0 se ha recibido correctamente. Por lo tanto, descarta estos datos D0 (ya que se han recibido
en el otro lado) y luego pasa al estado "Enviar D1", donde utilizará D1 para enviar el siguiente
dato solicitado.

 "Enviar D1". En este estado, B continúa respondiendo a los mensajes R1 recibidos enviando
D1 y luego permanece en este estado. Si B recibe un mensaje R1, entonces sabe que su mensaje
D1 se ha recibido correctamente y, por lo tanto, pasa al estado "Enviar D1".

22. Sea un protocolo GBN con un tamaño de ventana de emisor de 4 y un rango de números de
secuencia de 1.024. Suponga que en el instante t el siguiente paquete en orden que el receptor está
esperando tiene el número de secuencia k. Suponga que el medio de transmisión no reor-dena los
mensajes. Responda a las siguientes cuestiones:

a. ¿Cuáles son los posibles conjuntos de números de secuencia que pueden estar dentro de la
ventana del emisor en el instante t? Justifique su respuesta.
 b. ¿Cuáles son todos los valores posibles del campo ACK en todos los posibles mensajes que
están actualmente propagándose de vuelta al emisor en el instante t? Justifique su res-
puesta.

Aquí tenemos un tamaño de ventana de N = 3. Suponga que el receptor ha recibido el paquete k-1 y ha
ACKED ese y todos los demás paquetes anteriores. Si el remitente ha recibido todos estos ACK, la
ventana del remitente es [k, k + N-1]. A continuación, suponga que el remitente no ha recibido ninguno
de los ACK. En este segundo caso, la ventana del remitente contiene k-1 y los N paquetes hasta k-1
inclusive. Por tanto, la ventana del remitente es [k-N, k-1]. Según estos argumentos, la ventana de los
remitentes es de tamaño 3 y comienza en algún lugar del rango [k-N, k].

Si el receptor está esperando el paquete k, entonces ha recibido (y ACKed) el paquete k-1 y los paquetes
N-1 antes. Si el remitente aún no ha recibido ninguno de esos N ACK, es posible que los mensajes ACK
con valores de [kN, k-1] aún se estén propagando. Debido a que el remitente ha enviado paquetes [kN,
k-1], debe ser el caso de que el remitente ya haya recibido un ACK para kN-1. Una vez que el receptor
ha enviado un ACK para k-N-1, nunca enviará un ACK que sea menor que k-N-1. Por lo tanto, el rango
de valores ACK en vuelo puede variar de k-N-1 a k-1.

23. Considere los protocolos GBN y SR. Suponga que el tamaño del espacio de números de
secuencia es k. ¿Cuál es la máxima ventana de emisor permitida que evitará la ocurrencia de
problemas como los indicados en la Figura 3.27 para cada uno de estos protocolos?

Para evitar el escenario de la Figura 3.27, queremos evitar que el borde anterior de la ventana del
receptor (es decir, el que tiene el número de secuencia "más alto") se envuelva en el espacio del número
de secuencia y se superponga con el borde posterior (el uno con el número de secuencia "más bajo" en
la ventana del remitente). Es decir, el espacio del número de secuencia debe ser lo suficientemente
grande para adaptarse a toda la ventana del receptor y toda la ventana del remitente sin esta condición
de superposición. Por lo tanto, necesitamos determinar qué tan grande se puede cubrir un rango de
números de secuencia en un momento dado por las ventanas del receptor y del remitente. Supongamos
que el número de secuencia más bajo que el receptor está esperando es el paquete m. En este caso, su
ventana es [m, m + w-1] y ha recibido (y ACKed) el paquete m-1 y los paquetes w-1 antes de eso, donde
w es el tamaño de la ventana. Si el remitente aún no ha recibido ninguno de esos w ACK, es posible
que los mensajes ACK con valores de [m-w, m-1] aún se estén propagando. Si el remitente no ha
recibido ningún ACK con estos números de ACK, entonces la ventana del remitente sería [mw, m-1].
Por lo tanto, el borde inferior de la ventana del remitente es mw y el borde anterior de la ventana de los
receptores es m + w-1. Para que el borde anterior de la ventana del receptor no se superponga con el
borde posterior de la ventana del remitente, el espacio del número de secuencia debe por lo tanto, será
lo suficientemente grande para acomodar 2 números de secuencia. Es decir, el espacio del número de
secuencia debe ser al menos dos veces mayor que el tamaño de la ventana, wk2.

24. Responda verdadero o falso a las siguientes preguntas y justifique brevemente sus respuestas:
a. Con el protocolo SR, el emisor puede recibir un ACK para un paquete que se encuentra fuera de su
ventana actual.
b. Con GBN, el emisor puede recibir un ACK para un paquete que se encuentra fuera de su ventana
actual.
c. El protocolo de bit alternante es igual que el protocolo SR pero con un tamaño de ventana en el emisor
y en el receptor igual a 1.
d. El protocolo de bit alternante es igual que el protocolo GBN pero con un tamaño de ven-tana en el
emisor y en el receptor igual a 1.

a. Verdadero. Suponga que el remitente tiene un tamaño de ventana de 3 y envía paquetes 1,

2, 3 a 0t. En 1t) 01 (tt>el receptor ACKS 1, 2, 3. En 2t) 12 (tt>el emisor agota el tiempo de
espera y reenvía 1, 2, 3. En 3t el receptor recibe los duplicados y vuelve a reconocer 1, 2, 3
Al 4, el remitente recibe los ACK que el receptor envió en 1 y avanza su ventana a 4, 5, 6.
Al 5, el remitente recibe los ACK 1, 2, 3 que el receptor envió a 2t. Estos ACK están fuera
de su ventana.
b. Verdadero. Básicamente por el mismo escenario que en (a).
c. Verdadero.
d. Verdadero. Tenga en cuenta que con un tamaño de ventana de 1, SR, GBN y el protocolo
de bits alternos son funcionalmente equivalentes. El tamaño de ventana de 1 excluye la
posibilidad de paquetes desordenados (dentro de la ventana). Un ACK acumulativo es
simplemente un ACK ordinario en esta situación, ya que solo puede referirse al paquete
individual dentro de la ventana.

25. Hemos dicho que una aplicación puede elegir UDP como protocolo de transporte porque UDP
ofrece a la aplicación un mayor grado de control (que TCP) en lo relativo a qué datos se envían
en un segmento y cuándo.
a. ¿Por qué una aplicación tiene más control sobre qué datos se envían en un segmento?
b. ¿Por qué una aplicación tiene más control sobre cuándo se envía el segmento?

a. Considere enviar un mensaje de aplicación a través de un protocolo de transporte. Con TCP,

la aplicación escribe datos en el búfer de envío de la conexión y TCP capturará bytes sin
necesariamente poner un solo mensaje en el segmento TCP; TCP puede poner más o menos
de un mensaje en un segmento. UDP, por otro lado, encapsula en un segmento lo que sea
que le dé la aplicación; de modo que, si la aplicación le da a UDP un mensaje de aplicación,
este mensaje será la carga útil del segmento UDP. Por lo tanto, con UDP, una aplicación
tiene más control sobre qué datos se envían en un segmento.
b. Con TCP, debido al control de flujo y control de congestión, puede haber un retraso
significativo desde el momento en que una aplicación escribe datos en su búfer de envío
hasta que los datos se entregan a la capa de red. UDP no tiene retrasos debido al control de
flujo y control de congestión.

26. Se desea transferir un archivo de gran tamaño de L bytes del host A al host B. Suponga un
MSS de 536 bytes.
a. ¿Cuál es el valor máximo de L tal que los números de secuencia de TCP no se agoten? Recuerde que
el campo número de secuencia de TCP tiene 4 bytes.
b. Para el valor de L que haya obtenido en el apartado (a), calcule el tiempo que tarda en transmitirse el
archivo. Suponga que a cada segmento se añade un total de 66 bytes para la cabecera de la capa de
transporte, de red y de enlace de datos antes de enviar el paquete resultante a través de un enlace a 155
Mbps. Ignore el control de flujo y el control de con-gestión de modo que A pueda bombear los
segmentos seguidos y de forma continuada.

Hay 232 secuencias posibles

a. Tamaño máximo que puede ser enviado es 4,19 Gbyts
b. El número de segmentos es 4,82X109

27. Los hosts A y B están comunicándose a través de una conexión TCP y el host B ya ha recibido
de A todos los bytes hasta el byte 126. Suponga que a continuación el host A envía dos segmentos
seguidos al host B. El primer y el segundo segmentos contienen, respectivamente, 80 y 40 bytes de
datos. En el primer segmento, el número de secuencia es 127, el número del puerto de origen es
302 y el número de puerto de destino es 80. El host B envía un paquete de reconocimiento cuando
recibe un segmento del host A.
a. En el segundo segmento enviado del host A al B, ¿cuáles son el número de secuencia, el número del
puerto de origen y el número del puerto de destino?
b. Si el primer segmento llega antes que el segundo segmento, ¿cuál es el número de reco-nocimiento,
el número del puerto de origen y el número del puerto de destino en el ACK correspondiente al primer
segmento?
c. Si el segundo segmento llega antes que el primero, ¿cuál es el número de reconocimiento en el ACK
correspondiente a este segmento?
d. Suponga que los dos segmentos enviados por A llegan en orden a B. El primer paquete de
reconocimiento se pierde y el segundo llega después de transcurrido el primer intervalo de fin de
temporización. Dibuje un diagrama de temporización que muestre estos segmentos y todos los restantes
segmentos y paquetes de reconocimiento enviados. (Suponga que no se producen pérdidas de paquetes
adicionales.) Para cada uno de los segmentos que incluya en su diagrama, especifique el número de
secuencia y el número de bytes de datos; para cada uno de los paquetes de reconocimiento que añada,
proporcione el número de recono-cimiento.

a. En el segundo segmento del Host A al B, el número de secuencia es 207, el número de

puerto de origen es 302 y el número de puerto de destino es 80.
b. Si el primer segmento llega antes que el segundo, en el acuse de recibo del primer segmento
de llegada, el número de acuse de recibo es 207, el número de puerto de origen es 80 y el
número de puerto de destino es 302.
c. Si el segundo segmento llega antes que el primer segmento, en el acuse de recibo del primer
segmento de llegada, el número de acuse de recibo es 127, lo que indica que todavía está
esperando los bytes 127 en adelante.
 d.
28. Los hosts Ay B están directamente conectados mediante un enlace a 100 Mbps. Existe una
conexión TCP entre los dos hosts y el host A está enviando al host B un archivo de gran tamaño
a través de esta conexión. El host A puede enviar sus datos de la capa de aplicación a su socket
TCP a una velocidad tan alta como 120 Mbps pero el host B solo puede leer los datos almacenados
en su buffer de recepción TCP a una velocidad máxima de 50 Mbps. Describa el efecto del control
de flujo de TCP.

El efecto de control de flujo de TCP en esta situación se describe de tal forma que dado la capacidad de
enlace de 100Mbps, la velocidad por tanto de envío del Host A puede ser de casi 100Mbps. Los datos
enviados por el host A al búfer de recepción de TCP se da con una velocidad de máximo 120Mbps, el
búfer de recepción se llena a una velocidad de aproximadamente 50 Mbps, el host B elimina datos del
búfer de recepción de TCP a 50 Mbps. Cuando el búfer se llena el host B establece un RcvWindow en
cero, siendo esta la señal para que A deje de enviar datos al búfer y espera hasta que recibe un segmento
TCP con RcvWindow>0. Con esto el host A se detendrá y comenzará a enviar datos según el valor de
RcvWindow que recibe el host A del host B. Por lo tanto, con esto se podría determinar que la velocidad
promedio a largo plazo a la que el host A envía datos al host B no debe sobrepasar los 50Mbps.

29. En la sección 3.5.6 se han estudiado las cookies SYN.

a. ¿Por qué es necesario que el servidor utilice un número de secuencia inicial especial en SYNACK?
En base a la sección 3.5.6 se observa que el servidor requiere una secuencia inicial especial en SYNACK
porque es necesario contra el ataque SYN FLOOD. Además, esta secuencia pertenece a una cookie
SYN (aquella que contiene un número secreto del que solo el servidor tiene conocimiento y protege la
información en el paquete de un ataque DoS)
b. Suponga que un atacante sabe que un host objetivo utiliza cookies SYN. ¿Puede el atacante crear
conexiones semi-abiertas o completamente abiertas enviando simplemente un paquete ACK al host
objetivo? ¿Por qué?
El atacante no podría crear conexiones semiabiertas o completamente abiertas con solo enviar un
paquete ACK al host objetivo. Porque las conexiones semiabiertas no son posibles ya que un servidor
que utiliza cookies SYN no mantiene las variables de conexión ni los búferes para ninguna conexión
antes de que se establezcan conexiones totales. En todo caso el atacante debería conocer el número de
secuencia inicial especial de la dirección IP de origen falsificada del atacante. Dicho número necesita
el número secreto que utiliza cada servidor.
c. Suponga que un atacante recopila una gran cantidad de números de secuencia iniciales enviados por
el servidor. ¿Puede el atacante hacer que el servidor cree muchas conexiones completamente abiertas
enviando paquetes ACK con esos números de secuencia iniciales? ¿Por qué?
Suponiendo la situación propuesta el atacante no podría hacer que el servidor cree muchas conexiones
completamente abiertas porque el server puede agregar una marca de tiempo para calcular una secuencia
inicial de números, elegir un tiempo de vida para cada uno y descartar números de secuencia iniciales
que caduquen incluso cuando el atacante trate de reproducirlos. Cabe mencionar que de forma teórica
esto podría ser posible pero de forma práctica resulta imposible por la cantidad de números de
secuencias requeridos.

30. Considere la red mostrada en el escenario 2 de la Sección 3.6.1. Suponga que ambos hosts
emisores A y B tienen definidos valores de fin de temporización fijos.

a. Demuestre que aumentar el tamaño del buffer finito del router puede llegar a hacer que se
reduzca la tasa de transferencia λ_out
Si los hosts emisores A y B tienen valores de fin de temporización fijos entonces los remitentes pueden
agotar de forma prematura el tiempo de espera. Entonces algunos de los paquetes se retransmiten
aunque no se pierdan.
b. Suponga ahora que ambos hosts ajustan dinámicamente sus valores de fin de temporización
(como lo hace TCP) basándose en el retardo del buffer del router. ¿Incrementar el tamaño
del buffer ayudaría a incrementar la tasa de transferencia? ¿Por qué?
Si ayudaría a incrementar la tasa de transferencia el incremento de buffer porque se estiman los valores
de tiempo de espera como en TCP, sin embargo puede existir un problema importante dado que el
retraso en la cola puede ser muy grande, similar a la situación presente en el escenario 1.
31. Suponga que los cinco valores de RTTMuestra medidos (véase la Sección 3.5.3) son 106 ms,
120 ms, 140 ms, 90 ms y 115 ms. Calcule el valor de RTTEstimado después de obtener cada uno
de estos valores de RTTMuestra, utilizando un valor de a 5 0,125 y suponiendo que el valor de
RTTEstimado era 100 ms justo antes de obtener el primero de estas cinco muestras. Calcule
también el valor de RTTDesv después de obtener cada muestra, suponiendo un valor de b 5 0,25
y que el valor de RTTDesv era de 5 ms justo antes de obtener la primera de estas cinco muestras.
Por último, calcule el IntervaloFinTemporización de TCP después de obtener cada una de estas
muestras.
DevRTT = (1- β) * DevRTT + β * | RTTMuestra - RTTEstimado |
RTTEstimado= (1-α) * RTTEstimado + α * RTTMuestra
TimeoutInterval = RTTEstimado + 4 * DevRTT
Después de obtener la primera muestra RTT en 106ms:
DevRTT = 0.75*5 + 0.25 * | 106 - 100 | = 5.25ms
RTTEstimado= 0.875 * 100 + 0.125 * 106 = 100.75 ms
TimeoutInterval = 100.75+4*5.25 = 121.75 ms

Para 120ms:
DevRTT = 0.75*5.25 + 0.25 * | 120 – 100.75 | = 8.75 ms
RTTEstimado = 0.875 * 100.75 + 0.125 * 120 = 103.16 ms
TimeoutInterval = 103.16+4*8.75 = 138.16 ms
Para 140ms:
DevRTT = 0.75*8.75 + 0.25 * | 140 – 103.16 | = 15.77 ms
RTTEstimado = 0.875 * 103.16 + 0.125 * 140 = 107.76 ms
TimeoutInterval = 107.76+4*15.77 = 170.84 ms
Para 90ms:
DevRTT = 0.75*15.77 + 0.25 * | 90 – 107.76 | = 16.27 ms
RTTEstimado = 0.875 * 107.76 + 0.125 * 90 = 105.54 ms
TimeoutInterval = 105.54+4*16.27 =170.62 ms
Para 115ms:
DevRTT = 0.75*16.27 + 0.25 * | 115 – 105.54 | = 14.57 ms
RTTEstimado = 0.875 * 105.54 + 0.125 * 115 = 106.72 ms
TimeoutInterval = 106.72+4*14.57 =165 ms

32. Considere el procedimiento de TCP para estimar RTT. Suponga que α=0,1. Sea RTTMuestra1
la muestra de RTT más reciente, RTTMuestra2 la siguiente muestra de RTT más reciente, y así
sucesivamente

a. Para una conexión TCP determinada, suponga que han sido devueltos cuatro paquetes de
reconocimiento con las correspondientes muestras de RTT, RTTMuestra4 , RTTMuestra3
, RTTMuestra2 y RTTMuestra1 . Exprese RTTEstimado en función de las cuatro muestras
de RTT.

Para las cuatro muestras:

RTTEstimado4
=xRTTmuestra1
+ (1- x)[xRTTmuestra2 + (1-x )[xRTTmuestra3+(1-x)xRTTmuestra4]]
= xRTTmuestra1 + (1- x)RTTmuestra2 + (1- x)^2 RTTmuestra3
+ (1- x)^3 RTTmuestra4

b. Generalize la fórmula para n muestras de RTT.

Para n muestras:

𝑛−1

𝑅𝑇𝑇𝐸𝑠𝑡𝑖𝑚𝑎𝑑𝑜 𝑛 = 𝑥 ∑(1 − 𝑥)𝑗−1 𝑅𝑇𝑇𝑀𝑢𝑒𝑠𝑡𝑟𝑎𝑗 + (1 − 𝑥)𝑛−1 𝑅𝑇𝑇𝑀𝑢𝑒𝑠𝑡𝑟𝑎𝑛

𝑗=1

c. En la fórmula del apartado (b), considere que n tiende a infinito. Explique por qué este
procedimiento de cálculo del promedio se conoce como media móvil exponencial.

∞ ∞
𝑥 1
𝑅𝑇𝑇𝐸𝑠𝑡𝑖𝑚𝑎𝑑𝑜 ∞ = ∑(1 − 𝑥)𝑗 𝑅𝑇𝑇𝑀𝑢𝑒𝑠𝑡𝑟𝑎𝑗 = ∑ 9𝑗 𝑅𝑇𝑇𝑀𝑢𝑒𝑠𝑡𝑟𝑎𝑗
1−𝑥 9
𝑗=1 𝑗=1

La altura se da por las muestras pasadas que decaen de forma exponencial.

33. En la Sección 3.5.3, se ha estudiado la estimación de RTT en TCP. ¿Por qué cree que TCP
evita medir RTTMuestra para los segmentos retransmitidos?

TCP evita medir el valor RTTMuestra en cada retransmisión porque se puede dar errores en la medición
de estos tiempos, por ejemplo, cuando se envía un segmento y luego se retrasmitió por cualquiera de
las causas conocidas, se inicia un nuevo RTTMuestra, pero si en ese transcurso llega el mensaje que
confirma que se recibió el primer paquete enviado, lo que causara que se detenga RTTMuestra, pero
este fue del primer segmento enviado, provocando que se calcule el valor incorrecto y en consecuencia
los tiempos de los timers usados serán inadecuados.

34. ¿Cuál es la relación entre la variable BaseEmision de la Sección 3.5.4 y la variable

UltimoByteRecibido de la Sección 3.5.5?
La variable de estado TCP BaseEmision es el número de secuencia del byte de reconocimiento más
antiguo; en consecuencia, BaseEmision–1 es el número de secuencia del último byte que se sabe que
ha sido recibido correctamente y en orden en el receptor, pues TCP usa ACK’s acumulativos y envía el
número del bit que desea recibir. Mientras tanto la variable UltimoByteRecibido nos indica el número
del último byte del flujo de datos que ha llegado procedente de la red y que se ha almacenado en el
buffer de recepción del host B. Entonces la relación es:

BaseEmision– 1 ≤ UltimoByteRecibido
35. ¿Cuál es la relación entre la variable UltimoByteRecibido de la Sección 3.5.5 y la variable “y”
de la Sección 3.5.4?

La variable “y” confirma la recepción de todos los bytes anteriores al número de byte y; por lo tanto al
sí y > BaseEmision, entonces el ACK está confirmando uno o más de los segmentos no reconocidos
anteriormente. En consecuencia, cuando el emisor recibe la señal de ACK sabe que se ha recibido
satisfactoriamente y-1 segmentos, pero en ese transcurso de tiempo se puede haber recibido más
segmentos en el receptor, por lo que la relación queda marcada por:

y– 1 ≤ UltimoByteRecibido
36. En la Sección 3.5.4 hemos visto que TCP espera hasta que ha recibido tres ACK duplicados
antes de realizar una retransmisión rápida. ¿Por qué cree que los diseñadores de TCP han
decidido no realizar una retransmisión rápida después de recibir el primer ACK duplicado
correspondiente a un segmento?
Esto se debe a que en el transcurso de envió se puede dar que los paquetes pueden tomar rutas distintas
y por ende lleguen en desorden al receptor, por lo que bastaría con que lleguen en desorden dos paquetes
para generar una retransmisión, por lo que este pequeño error generaría retransmisiones innecesarias.
En consecuencia, con el uso de tres ACK’s se necesita que dos paquetes lleguen antes de un primer
paquete enviado para proceder a retransmitir.

37. Compare GBN, SR y TCP (sin paquetes ACK retardados). Suponga que los valores de fin de
temporización de los tres protocolos son los suficientemente grandes como para que 5 segmentos
de datos consecutivos y sus correspondientes ACK puedan ser recibidos (si no se producen
pérdidas en el canal) por el host receptor (host B) y el host emisor (host A), respectivamente.
Suponga que el host A envía 5 segmentos de datos al host B y que el segundo segmento (enviado
desde A) se pierde. Al final, los 5 segmentos de datos han sido recibidos correctamente por el host
B.

a. ¿Cuántos segmentos ha enviado en total el host A y cuántos ACK ha enviado en total el

host B? ¿Cuáles son sus números de secuencia? Responda a esta pregunta para los tres
protocolos.
Con GBN:
A envía 9 segmentos, pues en un inicio envía los 5 segmentos y luego retransmite los segmentos desde
el 2 hasta el 5.
B envía 8 ACK’s, 4 con el número de secuencia 1, por la recepción y el tiple ACK por la pérdida del
segundo segmento; luego transmite los 4 ACK’s de los 4 segmentos restantes.

Con SR:
A envía 6 segmentos, pues en un inicio envía los 5 segmentos y repite únicamente el segmento 2, que
es el que se perdió.
B envía 5 ACK’s, primero envía los ACK’s de los cuatro paquetes recibidos y finalmente el ACK del
segmento 2 que es el que s recepta luego de la retransmisión.

Con TCP:
A envía 6 segmentos, pues en un inicio envía los 5 segmentos y repite únicamente el segmento 2, que
es el que se perdió.
B envía 5 ACK’s, primero envía los ACK’s de los cuatro paquetes recibidos y finalmente el ACK del
segmento 2 que es el que s recepta luego de la retransmisión.

b. Si los valores de fin de temporización para los tres protocolos son mucho mayores que 5
RTT, ¿qué protocolo entregará correctamente los cinco segmentos de datos en el menor
intervalo de tiempo?

TCP será más efectivo en estos casos ya que con TCP se tiene mayores tasas de retransmisión, es decir
retransmite más rápido, pues caer en una retransmisión por agotamiento de temporizador es muy grave
ya que debe reducir su tasa de trasmisión muy abruptamente.

38. En la descripción de TCP de la Figura 3.53, el valor del umbral, umbralAL, se define como
umbral=VentCongestion/2 en varios sitios y el valor de umbralAL se hace igual a la mitad del
tamaño de la ventana cuando se produce un suceso de pérdida. ¿Tiene que ser la velocidad a la
que el emisor está transmitiendo cuando se produce un suceso de pérdida aproximadamente igual
a VentCongestion segmentos por RTT? Explique su respuesta. Si su respuesta es no, ¿puede
sugerir una forma diferente en la que se podría fijar el valor de umbralAL?

Si, la velocidad de transmisión debe ser igual a Ventana de congetion/RTT, pues se ha detectado perdida
de segmentos por congestión o por control de flujo, por lo que si enviamos datos a una tasa mayor no
estaríamos liberando el canal, y por el contrario lo estaríamos sobrecargando, provocando que la
probabilidad de perdida aumente; en consecuencia la eficiencia de la transmisión seria baja.

39. Considere la Figura 3.46(b). Si 𝝀′𝒊𝒏 aumenta por encima de R/2, ¿puede λout incrementarse
por encima de R/3? Explique su respuesta. Considere ahora la Figura 3.46(c). Si 𝝀′𝒊𝒏 aumenta
por encima de R/2, ¿puede λout aumentar por encima de R/4 suponiendo que un paquete será
reenviado dos veces como media desde el router al receptor? Explique su respuesta
Si la tasa de llegadas aumenta más allá de R/2 en la figura entonces la tasa total de llegadas a la cola
excede la capacidad, lo que resulta en una pérdida creciente a medida que aumenta la tasa de llegadas.
Cuando la tasa de llegada es igual a R/2, uno de cada tres paquetes que salen de la cola es una
retransmisión.
Con una mayor pérdida, una fracción mayor de los paquetes que salen de la cola se tratara de
retransmisiones. Dado que la tasa máxima de salida de la cola para una de las sesiones es R/2, y dado
que un tercio o más serán transmisiones a medida que aumenta la tasa de llegada, el rendimiento para
entregar datos con éxito se truncara en λout. De forma similar, si la mitad de los paquetes que salen de
la cola son retransmisiones y la tasa máxima de paquetes de salida por sesión es R/2 entonces el valor
máximo de λout es (R/2)/2 = R/4.

39. Considere la Figura 3.58. Suponiendo que TCP Reno es el protocolo que presenta el
comportamiento mostrado en la figura, responda a las siguientes preguntas. En todos los casos,
deberá proporcionar una breve explicación que justifique su respuesta.

a. Identifique los intervalos de tiempo cuando TCP está operando en modo de arranque lento. Nota de
vídeo Examen del comportamiento de TCP
b. Identifique los intervalos de tiempo cuando TCP está operando en el modo de evitación de la
congestión.
c. Después del ciclo de transmisión 16, ¿se detecta la pérdida de segmento mediante tres ACK
duplicados o mediante un fin de temporización?
d. Después del ciclo de transmisión 22, ¿se detecta la pérdida de segmento mediante tres ACK
duplicados o mediante un fin de temporización?
e. ¿Cuál es el valor inicial de umbralAL en el primer ciclo de transmisión?
f. ¿Cuál es el valor de umbralAL transcurridos 18 ciclos de transmisión?
g. ¿Cuál es el valor de umbralAL transcurridos 24 ciclos de transmisión?
h. ¿Durante cuál ciclo de transmisión se envía el segmento 70?
i. Suponiendo que se detecta una pérdida de paquete después del ciclo de transmisión 26 a causa de la
recepción de un triple ACK duplicado, ¿cuáles serán los valores del tamaño de la ventana de congestión
y de umbralAL?
j. Suponga que se utiliza TCP Tahoe (en lugar de TCP Reno) y que se han recibido triples ACK
duplicados en el ciclo de transmisión 16. ¿Cuáles serán los valores del tamaño de la ventana de
congestión y de umbralAL en el ciclo de transmisión 19?
k. Suponga otra vez que se utiliza TCP Tahoe y que se produce un suceso de fin de temporización en el
ciclo de transmisión 22. ¿Cuántos paquetes han sido enviados entre los ciclos de transmisión 17 a 22,
ambos inclusive?
a. El inicio lento de TCP se da en los intervalos 1 a 6 y 23 a 26.
b. La prevención de la congestión de TCP se presenta en los intervalos 6 a 16 y 17 a 22.
c. Después de la ronda 16 de transmisión, la pérdida de paquetes se reconoce mediante un ACK triple
duplicado. Si hubiese un tiempo de espera, el tamaño de la ventana de congestión se habría reducido a
1.
d. Después de la ronda 22 de transmisión, se detecta la pérdida de segmento debido al tiempo de espera
y por lo tanto el tamaño de la ventana de congestión se establece en 1.
e. El umbral es inicialmente 32 ya que es en este tamaño de ventana donde se detiene el inicio lento y
comienza la prevención de la congestión.
f. El umbral se fija a la mitad del valor de la ventana de congestión cuando se detecta la pérdida de
paquetes. Cuando se detecta una pérdida durante la ronda 16 de transmisión, el tamaño de las ventanas
de congestión es 42. Por tanto, el umbral es 21 durante la ronda 18 de transmisión.
g. El umbral se establece en la mitad del valor de la ventana de congestión cuando se detecta la pérdida
de paquetes. Cuando se detecta una pérdida durante la ronda 22 de transmisión, el tamaño de las
ventanas de congestión es 29. Por lo tanto, el umbral es 14 tomando el piso inferior de 14,5, esto durante
la ronda 24 de transmisión.
h. El paquete 70 se envía en la séptima ronda de transmisión.
i. El umbral se fijará a la mitad del valor actual de la ventana de congestión, cuando ocurra la pérdida y
la ventana de congestión se fije al nuevo valor de umbral + 3 MSS. Por tanto, los nuevos valores del
umbral y la ventana serán 4 y 7 respectivamente.
j. El umbral es 21 y el tamaño de la ventana de congestión es 1.
k. En la ronda 17, 1 paquete, en la ronda 18, 2 paquetes, en la ronda 19, 4 paquetes, en la ronda 20, 8
paquetes, en la ronda 21, 16 paquetes, en la ronda 22, 21 paquetes. El número total es 52.

41. Utilice la Figura 3.55, que ilustra la convergencia del algoritmo AIMD de TCP. Suponga que
en lugar de un decrecimiento multiplicativo, TCP disminuye el tamaño de la ventana en una
cantidad constante. ¿Convergería el algoritmo AIAD resultante hacia un algoritmo de cuota
equitativa? Justifique su respuesta utilizando un diagrama similar al de la Figura 3.55.
En la figura realizada se puede ver que la relación de la disminución lineal en la pérdida entre la
conexión 1 y la conexión 2 es la misma, esto al ver que la relación de los incrementos lineales aumenta.
Los rendimientos nunca se salen del segmento de línea AB.
La relación de la disminución lineal en la pérdida entre la conexión 1 y la conexión 2 es 2 a 1, es decir,
siempre que hay una pérdida, la conexión 1 reduce su ventana al doble de la cantidad de la conexión 2.
Luego de suficientes pérdidas y aumentos posteriores, el rendimiento de la conexión 1 pasará a 0 y el
ancho de banda completo del enlace será ser asignado a la conexión 2.
42. En la Sección 3.5.4, hemos explicado que el intervalo de fin de temporización se duplica
después de un suceso de fin de temporización. Este mecanismo es una forma de control de
congestión. ¿Por qué TCP necesita un mecanismo de control de congestión basado en ventana
(como hemos estudiado en la Sección 3.7) además de un mecanismo de duplicación del intervalo
de fin de temporización?
Si TCP fuera un protocolo de parada y espera, entonces la duplicación del intervalo de tiempo de espera
sería suficiente como mecanismo de control de la congestión, sin embargo, TCP utiliza canalización y,
por lo tanto, no es un protocolo de parada y espera, esto permite al remitente tener varios segmentos
pendientes no reconocidos. La duplicación del intervalo de tiempo de espera no evita que un remitente
TCP envíe una gran cantidad de paquetes transmitidos por primera vez a la red, por lo tanto se necesita
un mecanismo de control de la congestión para detener el flujo de datos recibidos de la aplicación
anterior cuando hay signos de congestión en la red.
43. El host A está enviando un archivo de gran tamaño al host B a través de una conexión TCP.
En esta conexión nunca se pierden paquetes y los temporizadores nunca caducan. La velocidad
de transmisión del enlace que conecta el host A con Internet es R bps. Suponga que el proceso del
host A es capaz de enviar datos a su socket TCP a una velocidad de S bps, donde S = 10 · R.
Suponga también que el buffer de recepción de TCP es lo suficientemente grande como para
almacenar el archivo completo y que el buffer emisor solo puede almacenar un porcentaje del
archivo. ¿Qué impide al proceso del host A pasar datos de forma continua a su socket TCP a una
velocidad de S bps? ¿El mecanismo de control de flujo de TCP, el mecanismo de control de
congestión de TCP o alguna otra cosa? Razone su respuesta.
No existe peligro de desbordar el receptor, ya que el búfer de recepción del receptor puede contener
todo el archivo, además debido a que no hay pérdida y los reconocimientos se devuelven antes de que
expiren los temporizadores, el control de congestión de TCP no estrangula al remitente, sin embargo el
proceso en el host A no pasará datos continuamente al socket porque el búfer de envío se llenará
rápidamente. Una vez que el búfer de envío se llena, el proceso pasará datos a una velocidad promedio.
44. Se envía un archivo de gran tamaño de un host a otro a través de una conexión TCP sin
pérdidas. a. Suponga que TCP utiliza el algoritmo AIMD para su control de congestión sin fase
de arranque lento. Suponiendo que VentCongestion aumenta 1 MSS cada vez que se recibe un
lote de paquetes ACK y suponiendo que los intervalos RTT son aproximadamente constantes,
¿Cuánto tiempo tarda VentCongestion en aumentar de 6 MSS a 12 MSS (si no se producen
sucesos de pérdida de paquetes)? b. ¿Cuál es la tasa de transferencia media (en función de MSS
y RTT) para esta conexión hasta llegar al periodo RTT número 6?
a) Se necesita 1 RTT para aumentar VentCongestion a 7 MSS, se necesitan 2 RTT para aumentar a 8
MSS y 3 RTT para aumentar a 9 MSS. Se necesitan 4 RTT para aumentar a 10 MSS, 5 RTT para
aumentar a 11 MSS y 6 RTT para aumentar a 12 MSS.
b) En el primer RTT se envió 6 MSS, en el segundo RTT se envió 7 MSS, en el tercer RTT se envió 8
MSS, en el cuarto RTT se envió 9 MSS, en el quinto RTT se enviaron 10 MSS y en el sexto RTT, se
enviaron 11 MSS. En total 51 MSS. Por lo tanto el rendimiento promedio hasta 6 RTT es:
51𝑀𝑆𝑆
= 8.5 𝑀𝑆𝑆/𝑅𝑇𝑇
6 𝑅𝑇𝑇
45. Recuerde la descripción macroscópica de la tasa de transferencia de TCP. En el periodo de
tiempo que va desde que la velocidad de la conexión varía entre W/ (2 · RTT) y W/RTT, solo se
pierde un paquete (justo al final del periodo).

a) Demuestre que la tasa de pérdidas (fracción de paquetes perdidos) es igual a:

1
𝐿 = 𝑡𝑎𝑠𝑎 𝑑𝑒 𝑝é𝑟𝑑𝑖𝑑𝑎𝑠 =
3 2 3
𝑊 + 𝑊
8 4

La tasa de pérdidas L, es el radio de el número de paquetes perdidos sobre el número de paquetes

enviados. En un ciclo, 1 paquete es perdido. El número de paquetes enviados en un ciclo es:

𝑊 𝑊 𝑊 𝑊 𝑊
+ ( + 1) + ( + 2) + ⋯ + ( + )
2 2 2 2 2
𝑊 𝑊 𝑊
= + ( + 1) + ( + 2) + ⋯ + (𝑊)
2 2 2
𝑊/2
𝑊
= ∑ ( + 𝑛)
2
𝑛=0
𝑊/2
𝑊 𝑊
= ( + 1) + ∑ 𝑛
2 2
𝑛=0
La sumatoria de n términos está dada por:
𝑛
𝑛(𝑛 + 1)
∑𝑖 =
2
𝑖=0
𝑊 𝑊
𝑊 𝑊 2 ( 2 + 1)
= ( + 1) +
2 2 2

𝑊2 𝑊
𝑊 𝑊 ( + )
4 2
= ( + 1) +
2 2 2
 𝑊2 𝑊 𝑊2 𝑊
= + + +
4 2 8 4

3𝑊 2 3𝑊
= +
8 4

3𝑊 2 3𝑊
Entonces el número de paquetes en un ciclo es: +
8 4
La tasa de pérdida es:
1
𝐿=
3𝑊 2 3𝑊
( + )
8 4

b) Utilice el resultado anterior para demostrar que si una conexión tiene una tasa de pérdidas
igual a L, entonces su tasa promedio es aproximadamente igual a:
1.22 ∙ 𝑀𝑆𝑆
≈
𝑅𝑇𝑇√𝐿

Para valores muy grandes de W

3𝑊 2 3𝑊
≫
8 4
L se puede aproximar a:
1
𝐿≈
3𝑊 2
8
8
𝑊2 ≈ ( )
3𝐿

8
𝑊 = √( )
3𝐿
El rendimiento promedio de una conexión es:
3𝑊 𝑀𝑆𝑆
×
4 𝑅𝑇𝑇
Sustituyendo el valor de W calculado, se tiene:
3 8 𝑀𝑆𝑆 8 1 𝑀𝑆𝑆
√( ) × ≈ 0.75 × √( ) × √ ×
4 3𝐿 𝑅𝑇𝑇 3 𝐿 𝑅𝑇𝑇

0.75 × 1.632 × 𝑀𝑆𝑆

≈
𝑅𝑇𝑇 × √𝐿
 1.2247 × 𝑀𝑆𝑆
≈
𝑅𝑇𝑇 × √𝐿

La tasa promedio es:

1.2247 ∙ 𝑀𝑆𝑆
≈
𝑅𝑇𝑇√𝐿
46. Considere una única conexión TCP (Reno) que emplea un enlace a 10Mbps que no almacena
en buffer ningún dato. Suponga que este enlace es el único enlace congestionado entre los hosts
emisor y receptor. Suponga también que el emisor TCP tiene que enviar al receptor un archivo
de gran tamaño y que el buffer de recepción del receptor es mucho más grande que la ventana de
congestión. Haremos además las siguientes suposiciones: el tamaño de segmento TCP es de 1.500
bytes, el retardo de propagación de ida y vuelta de esta conexión es igual a 150 milisegundos y
esta conexión TCP siempre se encuentra en la fase de evitación de la congestión, es decir,
ignoramos la fase de arranque lento.

a. ¿Cuál es el tamaño máximo de ventana (en segmentos) que esta conexión TCP puede
alcanzar?

𝐶𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑 𝑑𝑒𝑙 𝑒𝑛𝑙𝑎𝑐𝑒 = 10𝑀𝑏𝑝𝑠

𝑀𝑆𝑆 = 1500 𝑏𝑦𝑡𝑒𝑠
𝑅𝑒𝑡𝑎𝑟𝑑𝑜 𝑑𝑒 𝑝𝑟𝑜𝑝𝑎𝑔𝑎𝑐𝑖ó𝑛 𝑏𝑖𝑑𝑖𝑟𝑒𝑐𝑐𝑖𝑜𝑛𝑎𝑙 𝑑𝑒 𝑒𝑠𝑡𝑎 𝑐𝑜𝑛𝑒𝑥𝑖ó𝑛 = 150𝑚𝑠𝑒𝑐
150 × 10−3
𝑅𝑇𝑇 =
8
= 0.01875 𝑚𝑠𝑒𝑐

Suponga que el tamaño máximo de la ventana = W.

Los paquetes se descartarán si la velocidad máxima de envío supera la capacidad del enlace.

𝑀𝑆𝑆
𝑊× = 10𝑀𝑏𝑝𝑠
𝑅𝑇𝑇
1500
𝑊× = 10 × 106
0.01875 𝑚𝑠𝑒𝑐

𝑊 × 80000 = 10 × 106

10 × 106
𝑊=
80000

𝑊 = 125

El máximo tamaño de la ventana es 125 segmentos

b. ¿Cuáles son el tamaño medio de ventana (en segmentos) y la tasa de transferencia media (en bps)
de esta conexión TCP?

Tamaño de la ventana promedio = 0.75 × 125

= 93.75
= 94

el tamaño promedio de la ventana es de 94 segmentos.

 94 × (1500 × 8)
𝑅𝑒𝑛𝑑𝑖𝑚𝑖𝑒𝑛𝑡𝑜 𝑝𝑟𝑜𝑚𝑒𝑑𝑖𝑜 =
150 × 10−3

𝑅𝑒𝑛𝑑𝑖𝑚𝑖𝑒𝑛𝑡𝑜 𝑝𝑟𝑜𝑚𝑒𝑑𝑖𝑜 = 7.52𝑀𝑏𝑝𝑠

c. ¿Cuánto tiempo tarda esta conexión TCP en alcanzar de nuevo su tamaño de ventana
máximo después de recuperarse de una pérdida de paquete?
𝑊
=
2 × 150 × 10−3

125
= × 0.15
2

= 9.375

Para aumentar el tamaño de la ventana de W / 2 a W para la conexión TCP, el número requerido de

RTT es W / 2. En cada RTT, el tamaño de la ventana aumenta en uno.

47. Continuando con el escenario descrito en el problema anterior, suponga que el enlace a
10Mbps puede almacenar en buffer un número finito de segmentos. Razone por qué para que el
enlace esté siempre ocupado enviando datos, deberíamos seleccionar un tamaño de buffer que sea
al menos igual al producto de la velocidad del enlace C y el retardo de propagación de ida y vuelta
entre el emisor y el receptor.

Sea W el tamaño máximo de la ventana. Sea S el tamaño del búfer. Por simplicidad, suponga
que el remitente TCP envía paquetes de datos ronda a ronda, con cada ronda
correspondiente a un RTT. Si el tamaño de la ventana alcanza W, se produce una pérdida.
Entonces el remitente reducirá el tamaño de la ventana de congestión a la mitad y esperará los
𝑊
ACK para paquetes pendientes antes de que comience a enviar segmentos de datos
2
nuevamente. Para estar seguro el enlace siempre está ocupado enviando datos, debemos dejar
que el enlace esté ocupado enviando datos en el período
𝑊
2𝐶
(este es el intervalo de tiempo en el que el remitente está esperando los ACK para el
W / 2 paquetes pendientes). Por tanto,
𝑊
𝑆≥
2
Sea 𝑇𝑝 el retardo de propagación unidireccional entre el emisor y el receptor.
𝑊
Cuando el tamaño de la ventana alcanza el mínimo y el búfer está vacío, necesitamos
2
asegurarnos de que el enlace también esté ocupado enviando datos. Por lo tanto, debemos
tener:
𝑊
2 ≥𝐶
2𝑇𝑝
𝑊
≥ 𝐶 × 2𝑇𝑝
2
Por tanto,
𝑆 ≥ 𝐶 × 2𝑇𝑝
48. Repita el Problema 46, pero sustituyendo el enlace a 10 Mbps por un enlace a 10 Gbps.
Observe que en la respuesta al apartado (c) habrá demostrado que se tarda mucho tiempo en que
el tamaño de la ventana de congestión alcance su máximo después de recuperarse de una pérdida
de paquete. Diseñe una solución que resuelva este problema.

𝐶𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑 𝑑𝑒𝑙 𝑒𝑛𝑙𝑎𝑐𝑒 = 10𝐺𝑏𝑝𝑠

𝑀𝑆𝑆 = 1500 𝑏𝑦𝑡𝑒𝑠

𝑅𝑇𝑇 = 150𝑚𝑠𝑒𝑐
𝑀𝑆𝑆
𝐶𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑 𝑑𝑒𝑙 𝑒𝑛𝑙𝑎𝑐𝑒 = 𝑊 ×
𝑅𝑇𝑇
a)
𝑀𝑆𝑆
𝑊× = 10 × 109 𝑏𝑝𝑠
𝑅𝑇𝑇
𝑊 = 125000 𝑠𝑒𝑔𝑚𝑒𝑛𝑡𝑜𝑠
b)
𝑊
(𝑊 + )
Tamaño de la ventana promedio = 2
2

3W
Tamaño de la ventana promedio =
4
Tamaño de la ventana promedio = 0.75 × 125000

Tamaño de la ventana promedio = 93750

0.75 × 125000
𝑅𝑒𝑛𝑑𝑖𝑚𝑖𝑒𝑛𝑡𝑜 𝑝𝑟𝑜𝑚𝑒𝑑𝑖𝑜 =
150 × 10−3

𝑅𝑒𝑛𝑑𝑖𝑚𝑖𝑒𝑛𝑡𝑜 𝑝𝑟𝑜𝑚𝑒𝑑𝑖𝑜? = 625𝐾𝑏𝑝𝑠

c) A continuación, se indica el tiempo que tarda la conexión TCP en alcanzar su ventana

máxima después de recuperarse de la pérdida de un paquete:
𝑊
( ) × 𝑅𝑇𝑇 = 9375𝑠𝑒𝑔
2
49. Sea T (medido en RTT) el intervalo de tiempo que una conexión TCP tarda en aumentar el
tamaño de su ventana de congestión de W/2 a W, donde W es el tamaño máximo de la ventana de
congestión. Demuestre que T es una función de la tasa de transferencia media de TCP.

Considerando que B denota el rendimiento promedio de una conexión.

𝑆𝑖 𝑢𝑛𝑎 𝑐𝑜𝑛𝑒𝑥𝑖ó𝑛 𝑡𝑖𝑒𝑛𝑒 𝑢𝑛𝑎 𝑡𝑎𝑠𝑎 𝑑𝑒 𝑝é𝑟𝑑𝑖𝑑𝑎 𝐿, 𝑒𝑛𝑡𝑜𝑛𝑐𝑒𝑠 𝑠𝑢 𝑟𝑒𝑛𝑑𝑖𝑚𝑖𝑒𝑛𝑡𝑜 𝑝𝑟𝑜𝑚𝑒𝑑𝑖𝑜

1.22 × 𝑀𝑆𝑆
𝐵=
𝑅𝑇𝑇√𝐿
Despejando L
1.22 × 𝑀𝑆𝑆
√𝐿 =
𝑅𝑇𝑇 × 𝐵
1.22 × 𝑀𝑆𝑆 2
𝐿=( )
𝑅𝑇𝑇 × 𝐵

El remitente TCP envía paquetes de 1 / L entre dos pérdidas de paquetes consecutivas.

 Por lo tanto, el intervalo de tiempo T es como se muestra a continuación:
1
( ) × 𝑀𝑆𝑆
𝑇= 𝐿
𝐵
𝑀𝑆𝑆
𝑇=
𝐿×𝐵
𝑀𝑆𝑆
𝑇=
1.22 × 𝑀𝑆𝑆 2
( ) ×𝐵
𝑅𝑇𝑇 × 𝐵
2
𝑅𝑇𝑇 × 𝐵
𝑇=
1.222 × 𝑀𝑆𝑆

Por tanto, T es una función del rendimiento promedio B de TCP.

50. Considere un algoritmo AIMD de TCP simplificado en el que el tamaño de la ventana de

congestión se mide en número de segmentos, no en bytes. En la fase de incremento aditivo, el
tamaño de la ventana de congestión se incrementa en un segmento cada RTT. En la fase de
decrecimiento multiplicativo, el tamaño de la ventana de congestión se reduce a la mitad (si el
resultado no es un entero, redondee al entero más próximo). Suponga que dos conexiones TCP,
𝑪𝟏 y 𝑪𝟐 , comparten un enlace congestionado cuya velocidad es de 30 segmentos por segundo.
Suponemos que tanto 𝑪𝟏 como 𝑪𝟐 están en la fase de evitación de la congestión. El intervalo RTT
de la conexión 𝑪𝟏 es igual a 50 milisegundos y el de la conexión 𝑪𝟐 es igual a 100 milisegundos.
Suponemos que cuando la velocidad de los datos en el enlace excede la velocidad del enlace, todas
las conexiones TCP experimentan pérdidas de segmentos de datos.

a) Si en el instante 𝒕𝟎 el tamaño de la ventana de congestión de ambas conexiones, 𝑪𝟏 y 𝑪𝟐 ,

es de 10 segmentos, ¿cuáles serán los tamaños de dichas ventanas de congestión después
de transcurridos 1.000 milisegundos?

La diferencia clave entre 𝐶1 y 𝐶2 es que el RTT de 𝐶1 es solo la mitad del de 𝐶2 . Por tanto, 𝐶1 ajusta el
tamaño de su ventana después de 50 mseg, pero 𝐶2 ajusta el tamaño de su ventana después de 100 mseg.
Suponga que cada vez que ocurre un evento de pérdida, 𝐶1 lo recibe después de 50 mseg y 𝐶2 lo recibe
después de 100 mseg. Además, tenemos el siguiente modelo simplificado de TCP. Después de cada
RTT, una conexión determina si debe aumentar el tamaño de la ventana o no. Para 𝐶1 , calculamos la
tasa de envío total promedio en el enlace en los 50 milisegundos anteriores. Si esa tasa excede la
capacidad del enlace, asumimos que 𝐶1 detecta pérdidas y reduce el tamaño de su ventana. Pero para
𝐶2 , calculamos la tasa de envío total promedio en el enlace en los 100 milisegundos anteriores. Si esa
tasa excede la capacidad del enlace, asumimos que 𝐶2 detecta pérdida y reduce el tamaño de su ventana.

La siguiente tabla describe la evolución de los tamaños de las ventanas y las tasas de envío según los
supuestos anteriores.

C1 C2
Tiempo (mseg) Tamaño de Tasa de Tamaño de Tasa de
ventana ventana de ventana ventana de
(número de envío de datos (número de envío de datos
segmentos promedio segmentos promedio
enviados en los (segmentos por enviados en los (segmentos por
 siguientes 50 segundo, = siguientes 100 segundo, =
mseg) Ventana/0.05) mseg) Ventana/0.1)
0 10 200 (en [0-50] 10 100 (en [0-50]
milisegundos) milisegundos)
50 5 (disminuye 100 (en [50-100] 100 (en [50-100]
tamaño de ms) milisegundos)
ventana como la
tasa promedio de
envío total al
enlace en los
últimos 50 ms es
300 = 200 + 100)
100 2 (disminuye 40 5 (disminuye 50
tamaño de tamaño de
ventana como la ventana como la
tasa promedio de tasa promedio de
envío total al envío total al
enlace en los enlace en los
últimos 50 ms es últimos 100 ms
200 = 100 + 100) es 250 =
(200 + 100) / 2 +
(100 + 100) / 2)
150 1 (disminuye 20 50
tamaño de
ventana como la
tasa promedio de
envío total al
enlace en los
últimos 50 ms es
90 = (40 + 50)
200 1 (no más 20 2 (disminuye 20
disminución, ya tamaño de
que el tamaño de ventana como la
la ventana ya es tasa promedio de
1) envío total al
enlace en los
últimos 100 ms
es 80 =
(40 + 20) / 2 +
(50 + 50) / 2)
250 1 (no más 20 20
disminución, ya
que el tamaño de
la ventana ya es
1)
300 1 (no más 20 1 (disminuye 10
disminución, ya tamaño de
que el tamaño de ventana como la
la ventana ya es tasa promedio de
1) envío total al
enlace en los
últimos 100 ms
es 40 =
(20 + 20) / 2 +
 (20 + 20) / 2)
350 2 40 10
400 1 20 1 10
450 2 40 10
500 1 (disminuye 20 1 10
tamaño de
ventana como la
tasa promedio de
envío total al
enlace en los
últimos 50 ms es
50 = (40 + 10)
550 2 40 10
600 1 20 1 10
650 2 40 10
700 1 20 1 10
750 2 40 10
800 1 20 1 10
850 2 40 10
900 1 20 1 10
950 2 40 10
1000 1 20 1 10

Según la tabla anterior, encontramos que después de 1000 mseg, los tamaños de ventana de 𝐶1 y 𝐶2 son
de 1 segmento cada uno.

b) ¿Obtendrán estas dos conexiones, a largo plazo, la misma cuota de ancho de banda del
enlace congestionado? Explique su respuesta.

No. A largo plazo, el ancho de banda compartido de 𝐶1 es aproximadamente el doble que el de 𝐶2 ,

porque 𝐶1 tiene un RTT más corto, solo la mitad del de 𝐶2 , por lo que 𝐶1 puede ajustar el tamaño de su
ventana dos veces más rápido que 𝐶2 . Si miramos la tabla anterior, podemos ver un ciclo cada 200
mseg, por ejemplo, de 850 mseg a 1000 mseg, inclusive. Dentro de un ciclo, la tasa de envío de 𝐶1 es
(40 + 20 + 40 + 20) = 120, que es tres veces más grande que el envío de 𝐶2 dado por (10 + 10 + 10 +
10) = 40.
51. Continúe con la red descrita en el problema anterior, pero ahora suponga que las dos
conexiones TCP, 𝑪𝟏 y 𝑪𝟐 , tienen el mismo intervalo RTT de 100 milisegundos. Suponga que en el
instante 𝒕𝟎 , el tamaño de la ventana de congestión de 𝑪𝟏 es de 15 segmentos, pero el tamaño de la
ventana de congestión de 𝑪𝟐 es igual a 10 segmentos.

a) ¿Cuáles serán los tamaños de las ventanas de congestión después de transcurridos 2.200
ms?

De manera similar al último problema, podemos calcular sus tamaños de ventana a lo largo del tiempo
en la siguiente tabla. Tanto 𝐶1 como 𝐶2 tienen el mismo tamaño de ventana 2 después de 2200 mseg.

C1 C2
Tiempo (mseg) Tamaño de Tasa de Tamaño de Tasa de
ventana ventana de ventana ventana de
(número de envío de datos (número de envío de datos
segmentos promedio segmentos promedio
enviados en los (segmentos por enviados en los (segmentos por
siguientes 100 segundo, = siguientes 100 segundo, =
mseg) Ventana/0.1) mseg) Ventana/0.1)
0 15 150 (en [0-100] 10 100 (en [0-100]
milisegundos) milisegundos)
100 7 70 5 50
200 3 30 2 20
300 1 10 1 10
400 2 20 2 20
500 1 10 1 10
600 2 20 2 20
700 1 10 1 10
800 2 20 2 20
900 1 10 1 10
1000 2 20 2 20
1100 1 10 1 10
1200 2 20 2 20
1300 1 10 1 10
1400 2 20 2 20
1500 1 10 1 10
1600 2 20 2 20
1700 1 10 1 10
1800 2 20 2 20
1900 1 10 1 10
2000 2 20 2 20
2100 1 10 1 10
2200 2 20 2 20

b) ¿Obtendrán estas dos conexiones, a largo plazo, la misma cuota de ancho de banda del
enlace congestionado?

Sí esto se debe al algoritmo AIMD de TCP y el propio TCP tienen el mismo RTT.

c) Decimos que dos conexiones están sincronizadas si ambas conexiones alcanzan su tamaño
de ventana máximo al mismo tiempo y alcanzan su tamaño mínimo de ventana también
 al mismo tiempo. ¿Terminarán con el tiempo sincronizándose estas dos conexiones? En
caso afirmativo, ¿cuáles son sus tamaños máximos de ventana?

Sí, esto se puede ver claramente en la tabla anterior. Su tamaño máximo de ventana es 2.

d) ¿Ayudará esta sincronización a mejorar la tasa de utilización del enlace compartido? ¿Por
qué? Esboce alguna idea para evitar esta sincronización.

No, esta sincronización no ayudará a mejorar la utilización del enlace, ya que estas dos conexiones
actúan como una sola conexión que oscila entre el tamaño de ventana mínimo y máximo. Por lo tanto,
el enlace no se utiliza completamente (recuerde que asumimos que este enlace no tiene búfer). Una
forma posible de romper la sincronización es agregar un búfer finito al enlace y soltar paquetes
aleatoriamente en el búfer antes de que se desborde. Esto hará que diferentes conexiones corten el
tamaño de sus ventanas en diferentes momentos. Hay muchas técnicas de AQM (Active Queue
Management) para hacer eso, como RED (Random Early Detect), PI (AQM proporcional e integral),
AVQ (Adaptive Virtual Queue) y REM (Random Exponential Marking).
52. Veamos una modificación del algoritmo de control de congestión de TCP. En lugar de utilizar
un incremento aditivo podemos emplear un incremento multiplicativo. Un emisor TCP
incrementa su tamaño de ventana según una constante pequeña positiva 𝒂 (𝟎 < 𝒂 < 𝟏) cuando
recibe un ACK válido. Halle la relación funcional existente entre la tasa de pérdidas 𝑳 y el tamaño
máximo de la ventana de congestión 𝑾. Demuestre que para esta conexión TCP modificada,
independientemente de la tasa media de transferencia de TCP, una conexión TCP siempre
invierte la misma cantidad de tiempo en incrementar el tamaño de su ventana de congestión de
𝑾/𝟐 a 𝑾.

Tenga en cuenta que 𝑊 representa el tamaño máximo de ventana. Primero podemos encontrar el
número total de segmentos enviados durante el intervalo cuando TCP cambia su tamaño de ventana de
𝑊/2 hasta e incluye 𝑊. Esto viene dado por:

𝑊 𝑊 𝑊 𝑊 𝑊
𝑆= + ( ) ∗ (1 + 𝛼) + ( ) ∗ (1 + 𝛼)2 + ( ) ∗ (1 + 𝛼)3 + ⋯ + ( ) ∗ (1 + 𝛼)𝑘
2 2 2 2 2

Encontramos que 𝑘 = 𝑙𝑜𝑔(1 + 𝛼)2, entonces 𝑆 = 𝑊 ∗ (2𝛼 + 1)/(2𝛼). La tasa de pérdida L viene
dada por:

1 (2𝛼)
𝐿 = =
𝑆 ( 𝑊 ∗ (2𝛼 + 1))

El tiempo que tarda TCP en aumentar el tamaño de su ventana de 𝑊/2 a 𝑊 viene dado por:
𝑘 ∗ 𝑅𝑇𝑇 = (𝑙𝑜𝑔(1 + 𝛼)2) ∗ 𝑅𝑇𝑇, que es claramente independiente del rendimiento medio de TCP.
Tenga en cuenta que el rendimiento promedio de TCP viene dado por:

𝑆 𝑀𝑆𝑆
𝐵 = 𝑀𝑆𝑆 ∗ =
(𝑘 + 1) ∗ 𝑅𝑇𝑇 (𝐿 ∗ (𝑘 + 1) ∗ 𝑅𝑇𝑇)

Tenga en cuenta que esto es diferente de TCP, que tiene un rendimiento promedio:

1.22 ∗ 𝑀𝑆𝑆
𝐵=
𝑅𝑇𝑇 ∗ √𝐿

donde la raíz cuadrada de 𝐿 aparece en el denominador.

53. En nuestra exposición sobre el futuro de TCP de la Sección 3.7 hemos destacado que, para
alcanzar una tasa de transferencia de 10 Gbps, TCP solo podría tolerar una probabilidad de
pérdida de segmentos de 𝟐𝒙𝟏𝟎−𝟏𝟎 (o lo que es equivalente, un suceso de pérdida por cada
5.000.000.000 segmentos). Indique de dónde se obtienen los valores 𝟐𝒙𝟏𝟎−𝟏𝟎 (1 por cada
5.000.000) para los valores de RTT y MSS dados en la Sección 3.7. Si TCP tuviera que dar soporte
a una conexión a 100 Gbps, ¿qué tasa de pérdidas sería tolerable?

Supongamos paquetes de 1500 bytes y un tiempo de ida y vuelta de 100 ms. Del rendimiento de TCP a
1.22∗𝑀𝑆𝑆
través de la ecuación 𝐵 = , tenemos
𝑅𝑇𝑇∗√𝐿

(1500 ∗ 8 𝑏𝑖𝑡𝑠)
10 𝐺𝑏𝑝𝑠 = 1.22 ∗
(0.1 𝑠𝑒𝑐 ∗ √𝐿)
14640 bits
√𝐿 = = 0.00001464
109 bits
𝐿 = 2.14 ∗ 10−10
54. En nuestra exposición sobre el control de congestión de TCP de la Sección 3.7, implícitamente
hemos supuesto que el emisor TCP siempre tiene datos que enviar. Consideremos ahora el caso
en que el emisor TCP envía una gran cantidad de datos y luego en el instante 𝒕𝟏 se queda inactivo
(puesto que no tiene más datos que enviar). TCP permanece inactivo durante un periodo de
tiempo relativamente largo y en el instante 𝒕𝟐 quiere enviar más datos. ¿Cuáles son las ventajas
y las desventajas de que TCP tenga que utilizar los valores de VentCongestion y umbralAL de 𝒕𝟏
cuando comienza a enviar datos en el instante 𝒕𝟐 ? ¿Qué alternativa recomendaría? ¿Por qué?

Una ventaja de utilizar los valores anteriores de cwnd y ssthresh en 𝑡2 es que TCP no tendría que pasar
por un inicio lento y evitar la congestión para aumentar hasta el valor de rendimiento obtenido en 𝑡1 .
Una desventaja de utilizar estos valores es que es posible que ya no sean precisos. En particular, si el
camino se ha vuelto más congestionado entre 𝑡1 y 𝑡2 , el remitente enviará una ventana grande de
segmentos a una ruta ya (más) congestionada.
55. En este problema vamos a investigar si UDP o TCP proporcionan un cierto grado de
autenticación del punto terminal.
a) Considere un servidor que recibe una solicitud dentro de un paquete UDP y responde a la
misma dentro de un paquete UDP (por ejemplo, como en el caso de un servidor DNS). Si un cliente
con la dirección IP X suplanta su dirección con la dirección Y, ¿a dónde enviará el servidor su
respuesta?

El servidor enviará su respuesta a Y.

b) Suponga que un servidor recibe un SYN con la dirección IP de origen Y, y después de responder
con un SYNACK, recibe un ACK con la dirección IP de origen Y y con el número de
reconocimiento correcto. Suponiendo que el servidor elige un número de secuencia inicial
aleatorio y que no existe ningún atacante interpuesto (man-in-the-middle), ¿puede el servidor
estar seguro de que el cliente está en la dirección Y (y no en alguna otra dirección X que esté
intentando suplantar a Y)?

El servidor puede estar seguro de que el cliente está efectivamente en Y. Si estuviera en alguna otra
dirección de suplantación de Y, el SYNACK se habría enviado a la dirección Y, y el TCP en ese host
no enviaría el segmento ACK de TCP de vuelta. Incluso si el atacante enviara un segmento TCP ACK
con el tiempo apropiado, no sabría el número de secuencia correcto del servidor (ya que el servidor usa
una secuencia inicial aleatoria
números.
56. En este problema, vamos a considerar el retardo introducido por la fase de arranque lento de
TCP. Se tiene un cliente y un servidor web directamente conectados mediante un enlace a
velocidad R. Suponga que el cliente desea extraer un objeto cuyo tamaño es exactamente igual a
15 S, donde S es el tamaño máximo de segmento (MSS). Sea RTT el tiempo de transmisión de ida
y vuelta entre el cliente y el servidor (suponemos que es constante). Ignorando las cabeceras del
protocolo, determine el tiempo necesario para recuperar el objeto (incluyendo el tiempo de
establecimiento de la conexión TCP) si

a) 4 S/R> S/R + RTT> 2 S/R

Refiriéndonos a la figura anterior, vemos que el retraso total es
RTT + RTT + S / R + RTT + S / R + RTT + 12S / R = 4RTT + 14 S / R

b) S/R + RTT> 4 S/R

De igual forma, el retraso en este caso es:
RTT + RTT + S / R + RTT + S / R + RTT + S / R + RTT + 8S / R = 5RTT +11 S / R

c) S/R >RTT
De igual forma, el retraso en este caso es:
RTT + RTT + S / R + RTT + 14 S / R = 3 RTT + 15 S / R