Capítulo 3

April 30, 2018 | Author: Tomas Tapia Iñiguez | Category: Transmission Control Protocol, Network Socket, Ip Address, Computer Standards, Internet
Share Embed Donate


Short Description

Descripción: preguntas kourose capitulo 3...

Description

Capítulo 3 Cuestiones de repaso SECCIONES 3.1 –3.3 R1. Suponga que la capa de red proporciona el siguiente servicio: la capa de red del host de origen acepta un segmento con un tamaño máximo de 1.200 bytes y una dirección de host de destino dest ino de la capa de transporte. La capa ca pa de red garantiza la entrega del segmento a la capa de transporte en el host de destino. Suponga que en el host de destino pueden ejecutarse muchos procesos de aplicaciones de red.

a. Diseñe el protocolo de la capa de transporte más simple posible que entregue los datos de la aplicación al proceso deseado en el host de destino. Suponga que el sistema operativo del host de destino ha asignado un número de puerto de 4 bytes a cada proceso de aplicación en ejecución. R/. Llame a este protocolo de transporte (STP). En el lado emisor, STP acepta desde el proceso de envío de un fragmento de datos que no exceda de 1.196 bytes, una dirección de host de destino y un número de puerto de destino. STP agrega cuatro bytes de cabecera de cada fragmento y pone el número de puerto del proceso de destino en este encabezado. STP entonces da la dirección del host de destino y el segmento resultante para la capa de red. La capa de red proporciona el segmento a STP en la host de destino. STP a continuación, continuación, examina el número de puerto en el segmento, extrae los datos del segmento, y pasa los datos al proceso identificado por el puerto número. b. Modifique este protocolo de manera que proporcione una “dirección de retorno” al proceso de destino. R/. El segmento tiene ahora dos campos de cabecera: un campo de puerto de origen y puerto de campo de destino. En el lado del remitente, STP acepta un bloque de datos que no exceda de 1.192 bytes, una dirección de destino de acogida, un número de puerto de origen, y un número de puerto de destino. STP crea un segmento que contiene el número de datos de la aplicación, el puerto de origen y el número de puerto de destino. Se da entonces el segmento y el host de destino frente a la capa de red. Después de recibir el segmento, STP en el receptor huésped le da al proceso de solicitud de los datos de las aplicaciones y el número de puerto de origen. c. En sus protocolos, ¿la capa de transporte “tiene que hacer algo” en el núcleo de la red de computadoras? R/. No, la capa de transporte no tiene que hacer nada en el núcleo, y el transporte capa "vive" en los sistemas finales.

R2. Imagine una sociedad en la que todo el mundo perteneciera a una familia de seis miembros, todas las familias vivieran en su propia casa, cada casa tuviera una dirección única y cada persona de cada casa ca sa tuviera un nombre único. Imagine que esa sociedad dispone de un servicio de correos que transpor ta las cartas desde una vivienda de origen hasta una vivienda de destino. El servicio de correos requiere que (i) la carta se introduzca en un sobre y que (ii) ( ii) la dirección de la casa de destino (y nada más) esté claramente escrita en el sobre. Suponga también que en cada familia hay un delegado que tiene asignada la tarea de recoger y distribuir las ca rtas a los restantes miembros de la familia. Las cartas no necesariamente proporcionan una indicación acerca de los destinatarios. a. Partiendo de la solución del Problema R1, describa un protocolo que el delegado de la familia pueda utilizar para entregar las cartas de un miembro de la familia emisora a un miembro de la familia receptora. R/. Para el envío de una carta, el miembro de la familia tiene la obligación de dar el nombre del delegado de la carta en sí, la dirección de la la casa de destino, y el nombre del destinatario. El delegado escribe claramente el nombre del destinatario en la parte superior de la carta. El delegado luego pone la carta en un sobre y escribe la dirección de la casa de destino en el mismo. El delegado luego le da la la carta a los servicio de correo. En el lado receptor, el delegado recibe la carta del servicio de correo, saca la carta del sobre y toma nota del nombre del destinatario escrito en la parte superior de la carta. El delegado entrega la carta al miembro de la familia con con este nombre. b. En su protocolo, ¿el servicio de correos tienen que abrir el sobre y examinar la carta para proporcionar este servicio? R/. No, el servicio de correos no tiene que abrir el sobre, sino que sólo examina la dirección en el sobre. R3. Considere una conexión TCP entre el host A y el host B. Suponga que los segmentos TCP que viajan del host A al host B tienen un número de puerto de origen x y un número de puerto de destino y. ¿Cuáles son los números de puerto de origen y de destino para los segmentos que viajan del host B al host A? R/. Número de puerto de origen y puerto de destino y el número X. R4. Describa por qué un desarrollador de aplicaciones puede decidir ejecutar una aplicación sobre UDP en lugar de sobre TCP. R/. Un desarrollador de aplicaciones no usa TCP por el control de congestión del TCP.  A menudo, los diseñadores de la telefonía telefonía IP y aplicaciones aplicaciones de videoconferencia IP eligen ejecutar sus aplicaciones a través de UDP porque quieren evitar la congestión de TCP de control. Además, algunas aplicaciones no necesitan la transferencia de datos fiable proporcionado por TCP.

R2. Imagine una sociedad en la que todo el mundo perteneciera a una familia de seis miembros, todas las familias vivieran en su propia casa, cada casa tuviera una dirección única y cada persona de cada casa ca sa tuviera un nombre único. Imagine que esa sociedad dispone de un servicio de correos que transpor ta las cartas desde una vivienda de origen hasta una vivienda de destino. El servicio de correos requiere que (i) la carta se introduzca en un sobre y que (ii) ( ii) la dirección de la casa de destino (y nada más) esté claramente escrita en el sobre. Suponga también que en cada familia hay un delegado que tiene asignada la tarea de recoger y distribuir las ca rtas a los restantes miembros de la familia. Las cartas no necesariamente proporcionan una indicación acerca de los destinatarios. a. Partiendo de la solución del Problema R1, describa un protocolo que el delegado de la familia pueda utilizar para entregar las cartas de un miembro de la familia emisora a un miembro de la familia receptora. R/. Para el envío de una carta, el miembro de la familia tiene la obligación de dar el nombre del delegado de la carta en sí, la dirección de la la casa de destino, y el nombre del destinatario. El delegado escribe claramente el nombre del destinatario en la parte superior de la carta. El delegado luego pone la carta en un sobre y escribe la dirección de la casa de destino en el mismo. El delegado luego le da la la carta a los servicio de correo. En el lado receptor, el delegado recibe la carta del servicio de correo, saca la carta del sobre y toma nota del nombre del destinatario escrito en la parte superior de la carta. El delegado entrega la carta al miembro de la familia con con este nombre. b. En su protocolo, ¿el servicio de correos tienen que abrir el sobre y examinar la carta para proporcionar este servicio? R/. No, el servicio de correos no tiene que abrir el sobre, sino que sólo examina la dirección en el sobre. R3. Considere una conexión TCP entre el host A y el host B. Suponga que los segmentos TCP que viajan del host A al host B tienen un número de puerto de origen x y un número de puerto de destino y. ¿Cuáles son los números de puerto de origen y de destino para los segmentos que viajan del host B al host A? R/. Número de puerto de origen y puerto de destino y el número X. R4. Describa por qué un desarrollador de aplicaciones puede decidir ejecutar una aplicación sobre UDP en lugar de sobre TCP. R/. Un desarrollador de aplicaciones no usa TCP por el control de congestión del TCP.  A menudo, los diseñadores de la telefonía telefonía IP y aplicaciones aplicaciones de videoconferencia IP eligen ejecutar sus aplicaciones a través de UDP porque quieren evitar la congestión de TCP de control. Además, algunas aplicaciones no necesitan la transferencia de datos fiable proporcionado por TCP.

R5. ¿Por qué razón el tráfico de voz y de vídeo suele enviarse sobre TCP en lugar de sobre UDP en la Internet de hoy día? (Sugerencia: la respuesta que estamos buscando no tiene nada que ver con el mecanismo de control de congestión de TCP.) R/. Como la mayoría de los servidores de seguridad están configurados para bloquear el tráfico UDP, utilizando TCP para vídeo, voz y permite que el tráfico de estos se establezca a pesar de la acción de los firewalls. R6. ¿Es posible que una aplicación disfrute de una transferencia de datos fiable incluso si se ejecuta sobre UDP? En caso afirmativo, explique cómo. R/. Sí. El desarrollador de la aplicación puede poner la transferencia de datos fiable en la aplicación aplicación y el protocolo de capa, sin embargo esto requeriría una cantidad significativa de trabajo y la depuración. R7. Sea un proceso del host C que tiene un socket UDP con el número de puerto 6789. Suponga también que los hosts A y B envían cada uno de ellos un segmento UDP al host C con el número de puerto de destino 6789. ¿Serán dirigidos ambos segmentos al mismo socket del host C? En caso afirmativo, ¿cómo sabrá el proceso del host C que estos dos segmentos proceden de dos hosts distintos? R/. Sí, ambos segmentos serán dirigidos a la misma toma. Para que cada uno reciba un segmento en la interfaz interfaz de socket, el sistema operativo proporcionará el proceso con las direcciones IP para determinar el origen de los segmentos individuales. R8. Suponga que un servidor web se ejecuta en el puerto 80 del host C. Suponga también que este servidor web utiliza conexiones persistentes y que actualmente está recibiendo solicitudes de dos hosts diferentes, A y B. ¿Están siendo enviadas todas las solicitudes al mismo socket del host C? Si están siendo pasadas a través de sockets diferentes, ¿utilizan ambos sockets el puerto 80? Explique y justifique su respuesta. R/. Para cada conexión persistente, el servidor Web crea una conexión independiente " socket ". Cada caja de conexión se identifica así en sus cuatro campos: (fuente IP dirección, número de puerto de origen, la dirección IP de destino, número de puerto de destino). Cuando el anfitrión C recibe datagramas IP, examina estos cuatro campos en el datagrama / segmento para determinar a qué socket debe pasar la carga útil del segmento TCP. Por lo tanto, las peticiones de A y B pasan a través de diferente toma. El identificador para ambos de estos zócalos tiene 80 para el puerto de destino, sin embargo, los identificadores para estos conectores tienen valores valores diferentes para direcciones IP de origen.

 A diferencia de UDP, cuando la capa de transporte pasa la la carga útil útil de un segmento TCP con el proceso de solicitud, que no especifica la dirección IP de origen, ya que implícitamente esta especificado por el identificador de socket. R9. En los protocolos estudiados, ¿por qué necesitábamos introducir números de secuencia? R/. Los números de secuencia son necesarios para un receptor, así podra averiguar si llega un paquete que contiene nuevos datos, eso seria una retransmisión. R10. En los protocolos rdt estudiados, ¿por qué necesitábamos introducir temporizadores? R/. Para manejar las perdidas en el canal, ya que los ACK al no ser recibidos o los NACK en la duración del temporizador estos serán retransmitidos. R11. Suponga que el retardo de ida y vuelta entre el emisor y el receptor es constante y conocido por el emisor. ¿Se necesitaría en este caso un temporizador en el protocolo rdt 3.0, suponiendo que los paquetes pued en perderse? Explique su respuesta. R/. Sin importar que sea constante y conocido por el emisor, será necesario un temporizador en el protocolo, ya que solo se garantizara la pérdida del paquete por el emisor. R12. Visite el applet de Java Go-Back-Nen el sitio web del libro. a. Haga que el emisor envíe cinco paquetes y luego detenga la animación antes de que cualquiera de los cinco paquetes paque tes alcance su destino. A continuación, elimine el primer paquete y reanude la animación. Describa lo que ocurre. b. Repita el experimento, pero ahora deje que el primer paquete alcance su destino y elimine el primer paquete de reconocimiento. Describa lo que ocurre. d. Para terminar, pruebe a enviar seis paquetes. ¿Qué ocurre? R13. Repita el problema R12, pero ahora utilizando el applet de Java con repetición selectiva (SR). ¿En qué se diferencian los protocolos SR y GBN? SECCIÓN 3.5 R14. ¿Verdadero o falso? a. El host A está enviando al host B un archivo de gran tamaño a través de una conexión TCP. Suponga que el host B no tiene datos que enviar al host A. El host B no enviará paquetes de reconocimiento al host A porque el host B no puede superponer esos reconocimientos sobre los datos.

R/. Falsa b. El tamaño de la ventana de recepción de TCP nunca varía mientras dura la conexión. R/. Falsa c. Suponga que el host A está enviando al host B un archivo de gran tamaño a través de una conexión TCP. El número de bytes no reconocidos que A envía no puede exceder el tamaño del buffer del receptor. R/. Verdadera d. Suponga que el host A está enviando al host B un archivo de gran tamaño a través de una conexión TCP. Si el número de secuencia de un segmento en esta conexión es m, entonces el número de secuencia del siguiente segmento necesariamente tiene que ser m+ 1. R/. Falsa e. El segmento TCP contiene un campo en su cabecera para Ventana Recepción. R/. Verdadera f. Suponga que el último RTT Muestra en una conexión TCP es igual a 1 segundo. El valor actual del Intervalo Fin De Temporización para la conexión será necesariamente 1 segundo. R/. Falsa g. Suponga que el host A envía al host B un segmento con el número de secuencia 38 y 4 bytes de datos a través de una conexión TCP. En este mismo segmento el número de reconocimiento necesariamente tiene que ser 42. R/. Falsa R15. Suponga que el host A envía dos segmentos TCP seguidos al host B a través de una conexión TCP. El primer segmento tiene el número de secuencia 90 y el segundo tiene el número de secuencia 110. a. ¿Cuántos datos hay en el primer segmento? R/. 20 bytes

b. Suponga que el primer segmento se pierde pero el segundo llega a B. En el paquete de reconocimiento que el host B envía al host A, ¿cuál será el número de reconocimiento? R/. Numero ACK = 90 R16.Considere el ejemplo de la conexión Telnet de la Sección 3.5. Unos pocos segundos después de que el usuario escriba la letra ‘C’, escribe la letra ‘R’. Después de escribir la letra ‘R’, ¿cuántos segmentos se envían y qué valores se almacenan en los campos número de secuencia y número de reconocimiento de los segmentos? R/. 3 segmentos. Primer segmento: ss = 43, ACK = 80; Segundo segmento: ss = 80,  ACK = 44; en tercer segmento: ss = 44, ACK = 81 SECCIÓN 3.7 R17. Suponga que existen dos conexiones TCP en un cierto enlace de cuello de botella con una velocidad de Rbps. Ambas conexiones tienen que enviar un a rchivo de gran tamaño (en la misma dirección a través del enlace de cuello de botella). Las transmisiones de los archivos se inician en el mismo instante. ¿Qué velocidad de transmisión podría proporcionar TCP a cada una de las conexiones? R/. La mitad para ambos R18. ¿Verdadero o falso? En el control de congestión de TCP, si el temporizador del emisor caduca, el valor de umbral se hace igual a la mitad de su valor anterior. R/. Falso, se establece en la mitad del valor actual de la ventana de congestión.

Capítulo 3 Problemas 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 p uerto de origen y de destino para: a. Los segmentos enviados de A a S. Puerto Origen

Puerto Destino

2555 50 b. Los segmentos enviados de B a S.

Puerto Origen

Puerto Destino

415

50

c. Los segmentos enviados de S a A. Puerto Origen

Puerto Destino

50

2555

d. Los segmento enviados de S a B. Puerto Origen

Puerto Destino

50

415

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? R/: Si f. ¿Qué ocurre si A y B son el mismo host? R/: No pueden 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? R/: 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 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, 01010100, 01110100.

¿Cuál es el complemento a 1 de la suma de estos bytes? (Observe que aunque UDP y TCP utilizan 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? R/:

1 0 1 0 0 1 1 + 1 0 1 0 1 0 0 1 0 1 0 0 1 1 1

1 0 1 0 0 1 1 1 + 0 1 1 1 0 1 0 0 0 0 1 0 1 1 0 0

El complemento a 1 de la suma 00101100 es 11010011 Se suman los dos primeros bytes de 8 bits y el resultado de esta se suma con el tercer byte, pero en esta se debe tener en cuenta el desbordamiento que va sobre el bit de menor peso, por lo tanto este complemento a 1 se obtiene convirtiendo todos los 0 a 1 y viceversa. La razón por la que UDP utiliza este complemento es porque no existe ninguna garantía de que todos los enlaces existentes entre el origen y el destino proporcionen un mecanismo de comprobación de errores; es decir, uno de los enlaces puede utilizar un protocolo de la capa de enlace que no proporcione comprobación de errores. En el receptor, los cuatro bytes de 8 bits se suman, incluyendo la suma de comprobación. Si no se han introducido errores en el paquete, entonces la suma en el receptor tiene que ser 11111111. Si uno de los bits es un 0, entonces sabemos que el paquete contiene errores. Todos los errores de un bit se detectarán, pero los errores de dos bits pueden ser detectados (por ejemplo, si el último dígito de la primera palabra se convierte en un 0 y el último dígito de la segunda palabra se convierte en un 1). 4. a. Suponga que tiene los 2 bytes siguientes: 01011100 y 01010110. ¿Cuál es el complemento a 1 de la suma de estos 2 bytes? R/: Sumando los dos bytes da 10110010 Tomando el complemento a 1 le da 01001101 b. Suponga que tiene los 2 bytes siguientes: 11011010 y 00110110. ¿Cuál es el complemento a 1 de la suma de estos 2 bytes?

R/: Sumando los dos bytes 100010000 Tomando el complemento a 1 le da 011101111 a. 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. R/: El primer byte 01011110 y el segundo byte 01010100 obteniendo así la suma de los bytes 10110010 y observando que no varía junto con el complemento 01001101. 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. R/: No, el receptor no puede estar seguro de que no se han producido errores de bit. Debido a la forma en la que se calcula la suma de comprobación para el paquete. Ya que UDP tiene que proporcionar un mecanismo de detección de errores en la capa de transporte, terminal a terminal, debido a que los segmentos se transfieren correctamente a través del enlace pero es posible que se introduzcan errores de bit cuando un segmento se almacena en la memoria de un router. Dado que no están garantizadas ni la fiabilidad enlace a enlace, ni la detección de errores durante el almacenamiento en memoria. 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. R/: Supongamos que el remitente se encuentra en estado de "espera la llamada 1 desde arriba" y el receptor se encuentra en estado "Espere 1 de abajo" El emisor envía un paquete con número de secuencia 1, y las transiciones a "Esperar ACK o NAK 1," en espera de un ACK o NAK Supongamos ahora que el receptor recibe el paquete con número de secuencia 1 correctamente, envía un ACK, y las transiciones al estado "Espere a 0 desde abajo", a la espera de 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, no vuelve a enviar el paquete con número de secuencia 1 Sin embargo, el receptor está esperando un paquete con número de secuencia 0 y (como se muestra en el problema del trabajo a domicilio) siempre envía una NAK cuando no recibe un paquete con número de secuencia 0 Por lo tanto el remitente siempre estará enviando un paquete con número de secuencia 1, y el receptor siempre NAK. 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?

R/: En primer lugar Vimos que el remitente debe números de sec uencia para que el receptor puede determinar si un paquete de datos es un duplicado de un paquete de datos ya recibidos En el caso de los ACK, el emisor no necesita esta información (es decir, un número de secuencia de un ACK) para decirle detectar un ACK duplicado. Un ACK duplicado es obvio para el receptor rdt3.0, y desde entonces ha recibido el ACK original, que la transición al siguiente estado, el ACK duplicado no es el ACK de las necesidades del remitente y por lo tanto es ignorado por el remitente rdt3.0 8. Dibuje la máquina de estados finitos correspondiente al lado receptor del protocolo rdt3.0. R/: La parte remitente de protocolo rdt3.0 difiere de la parte remitente de protocolo 2.2 en que los tiempos de espera se han agregado. Hemos visto que la introducción de los tiempos de espera se suma la posibilidad de paquetes duplicados en el flujo de datos entre el remitente y el receptor. Sin embargo, el receptor en protocolo rdt.2.2 ya puede manejar paquetes duplicados (Duplicados Receptor-secundarios en rdt 2.2 surgirían si el receptor envía un ACK que se ha bía perdido, y el remitente entonces retransmitido los datos antiguos) Por lo tanto el receptor en protocolo rdt2.2 también funcionará como el receptor en 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. Utilice un esquema similar al mostrado en la Figura 3.16. 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. 11. 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 sólo 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.) R/: El protocolo aún funciona, ya que una retransmisión sería lo que ocurriría si el paquete recibido con errores de hecho se ha perdido (y desde el punto de vista del receptor, nunca sabe cuál de estos eventos, si bien, ocurrirá) Hay que tener en cuenta que se producen tiempos de espera prematuros. En este caso, si se ACK de cada copia adicional del paquete y cada uno recibió ACK adicional provoca otra copia extra del paquete actual para ser enviados, el número de veces que los n paquetes enviados aumentará sin límite cuando tiende a infinito 12. Considere el protocolo rdt 3.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. 13. Considere un protocolo de transferencia de datos fiable que sólo 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 un o 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 sólo emplee paquetes NAK a otro que utilice paquetes ACK? ¿Por qué? R/: En un único protocolo de NAK, la pérdida de paquetes x sólo es detectada por el receptor cuando se recibe paquetes x 1 Es decir, los receptores recibe x-1 y entonces x 1, sólo cuando x 1 se recibe el receptor no darse cuenta de que x se perdió Si hay un gran retraso entre la transmisión de x y la transmisión de x 1, entonces será un largo tiempo hasta que x puede ser recuperado, en virtud de un único protocolo de NAK. Por otro lado, si se está enviando datos a menudo, entonces la recuperación bajo un NAK-único esquema podría suceder rápidamente. Por otra parte, si los errores son poco frecuentes, NAK se envían sólo ocasionalmente (cuando sea necesario), y nunca se envían ACK - una reducción significativa de retroalimentación en el NAKúnico caso en el caso de sólo ACK 14. 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 95 por ciento? Suponga que el tamaño de un paquete es de 1.500 bytes, incluyendo tanto los campos de cabecera como los datos. R/: Están a 12 microsegundos (o 0.012 milisegundos) para enviar un paquete, como 1500 * 8/10^9 = 12 microsegundos. Para que el remitente pueda estar ocupado el 95 por ciento del tiempo, debemos tener: Útil=0.95=(0.012n)/30.012 o n aproximadamente 2.376 paquetes 15. 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 aumentar la tasa de utilización del canal? ¿Por qué? ¿Existe algún problema potencial con esta técnica? Explique su respuesta. R/: Sí, En realidad, esto hace que el remitente pueda enviar una serie de datos segmentados en el canal. Sí. Este es un problema potencial Si los segmentos de datos se pierden en el canal, entonces el remitente del rdt 3.0 no va volver a enviar esos segmentos, a menos que haya algún mecanismo adicional en la aplicación de recuperarse de la pérdida. 16. 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. Des criba el formato de los paquetes intercambiados por el emisor y el receptor. 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 paquetes.

17. 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 transpor tado 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 separa 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. 18. 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. 19. Sea un protocolo GBN con una ventana de emisor de 3 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 reordena 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. R/: Aquí tenemos un tamaño de ventana de N = 3. Supongamos que el receptor ha recibido paquete k-1, ACK y todos los demás paquetes precede ntes. Si todos estos  ACK de haber sido recibidos por el remitente, entonces la ventana del remitente es [k, k + N-1]. Supongamos ahora que ninguno de los ACK puedo haber sido recibido por el remitente, entonces la ventana del emisor contiene K-1 y la N paquetes incluyendo K-1. La ventana del emisor es por lo tanto [k-n, k-1]. Por estos argumentos, la ventana de remitentes es de tamaño 3 y comienza en algún lugar en el rango [k N, k]. 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 respuesta. R/: Si el receptor está a la espera de paquete k, entonces se ha recibido (Ack) de paquete k-1 y los paquetes de N-1 antes de eso. Si ninguno de aquellos N ACK se han recibido aún por el remitente, los mensajes ACK con valores de [k N, k-1] aún se pueden ir propagando hacia atrás. Debido a que el remitente ha enviado paquetes [k N, k-1], tiene que ser el caso de que el remitente ya ha recibido un ACK para kN-1. Una vez que el receptor ha enviado un ACK para k N-1 que nunca le enviará un ACK que es menos que k N-1. Así, la gama de valores de ACK en vuelo puede variar desde k N-1 a k-1. 20. 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. Sólo 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 en tidad A, como se ha explicado anteriormente. Utilice sólo aquellos mecanismos que sean abso lutamente necesarios. R/: Debido a que el canal de A a B puede perder mensajes de petición, A necesitará tiempo de espera y retransmitir sus mensajes de solicitud (para ser capaz de

recuperarse de la pérdida). Debido a que los retrasos de canal son variables y desconocidos, es posible que uno enviará peticiones duplicadas (es decir, volver a enviar un mensaje de petición que ya ha sido recibido por B). Para ser capaz de detectar mensajes de solicitud de duplicados, el protocolo utiliza números de secuencia. Un número de secuencia de 1 bit será suficiente para un tipo parada y espera del protocolo de solicitud / respuesta.  A (el solicitante) tiene 4 estados: “Esperar la Solicitud de 0 desde arriba. " Aquí el solicitante está esperando una llamada de arriba para solicitar una unidad de datos. Cuando se recibe una solicitud desde arriba, envía un mensaje de solicitud, R0, a B, se inicia un temporizador y hace una transición al estado " Espere a D0”. Cuando en el " Esperar a Solicitud 0 desde arriba " del Estado, ignora cualquier cosa que recibe de B. “Espere a D0 “. Aquí el solicitante está esperando un mensaje de datos D0 de B. Un temporizador siempre se está ejecutando en este estado. Si el tiempo se agota, A envía otro mensaje R0, se reinicia el temporizador y permanece en este estado. Si se recibe un mensaje D0 de B, A se para el tiempo y el tránsito al estado " Espere Solicitud 1 desde arriba”. Si A recibe un mensa je de datos D1, mientras que en este estado, se ignora. “Esperar a Solicitud 1 desde arriba. " Aquí el solicitante está de nuevo a la espera de una llamada de arriba para solicitar una unidad de datos. Cuando se recibe una solicitud desde arriba, envía un mensaje de solicitud, R1, a B, se inicia un temporizador y hace una transición al estado " Espere D1” . Cuando en el Estado del " Esperar a Solicitud 1 desde arriba ", ignora cualquier cosa que recibe de B. “Espere a D1”. Aquí el solicitante está esperando un mensaje de datos D1 de B. Un temporizador siempre se está ejecutando en este estado. Si el tiempo se agota, A envía otro mensaje de R1, se reinicia el temporizador y permanece en este estado. Si se recibe un mensaje D1 de B, A se detiene el temporizador y tránsitos para el estado " Espere Solicitar 0 desde arriba”. Si A recibe un mensaje de datos D0 en este estado, se ignora. El proveedor de datos (B) tiene sólo dos estados: “Enviar D0. " En este estado, B sigue respondiendo a los mensajes recibidos por el envío de R0 D0, y luego permanece en este estado. Si B recibe un mensaje R1, luego se conoce su mensaje D0 ha sido recibido correctamente. Por lo tanto, descarta estos datos D0 (ya que se ha recibido en el otro lado) y, a continuación transita al estado " Enviar D1 “, donde se utilizará D1 a enviar la siguiente pieza de datos solicitada. “Enviar D1. " En este estado, B sigue respondiendo a los mensajes recibidos por el envío de R1 D1, y luego permanece en este estado. Si B recibe un mensaje R1,

entonces se conoce su mensaje D1 se ha recibido correctamente y por lo tanto transita al estado " Enviar D1" 21. 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? R/: Con el fin de evitar el escenario de la figura 3.27, queremos evitar que el borde delantero de la ventana del receptor (es decir, el que tiene el número de secuencia " más alto ") envolverlo alrededor, en el espacio de número de secuencia y se solapa con el borde de salida (el uno con el número de secuencia "mínimo" en la ventana del emisor). Es decir, el espacio de números de secuencia debe ser lo suficientemente grande como para ajustarse a la ventana del recep tor entero y toda la ventana del remitente, sin esta condición se superponen. Por lo tanto necesitamos para determinar el tamaño del rango de números de secuencia y se puede cubrir en un momento dado por las ventanas receptores y emisores. Supongamos que el número más bajo de secuencia que el receptor está esperando es de paquetes m. En este caso, la ventana es [m, m + w - 1] y ha recibido ( Ack) de paquetes m - 1 y los paquetes W-1 antes, donde w es el tamaño de la ventana. Si ninguno de esos ACK w se han recibido aún por el remitente, los mensajes ACK con valores de [m-w, m- 1] aún pueden ir propagánd ose hacia atrás. Si no hay ACK con estos números que han sido recibidos por el emisor, a continuación, la ventana del emisor sería [m-w, m- 1]. Por lo tanto, el borde inferior de la ventana del emisor es MW, y el borde delantero de la ventana de receptores es m + W - 1. Para que el borde de ataque de la ventana del receptor no pueda solaparse con el borde de salida de la ventana del emisor, el espacio de números de secuencia por lo tanto debe ser lo suficientemente grande para dar cabida a 2w números de secuencia. Es decir, el espacio de números de secuencia debe ser al menos dos veces tan grande como el tamaño de la ventana, k ≥ 2w

22. 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. R/: Verdadero. Supongamos que el remitente tiene un tamaño de ventana de 3 y envía los paquetes 1, 2, 3 en T0. En T1 (t1 > t0) el receptor ACK 1, 2, 3. En T2 (t2

> t1) los tiempos remitente fuera y vuelve a enviar 1, 2, 3. En T3 el receptor recibe los duplicados y vuelve a reconocer 1, 2, 3. En T4 el emisor recibe los ACK que el receptor envía al T1 y avanza en su ventana de 4, 5, 6. En T5 el remitente recibe el  ACK 1, 2, 3 el receptor enviado a T2. Estos ACK son fuera de su ventana b. Con GBN, el emisor puede recibir un ACK para un paquete que se encuentra fuera de su ventana actual. R/: Verdadero. Esencialmente por el mismo escenario que en a. 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. R/: Verdadero d. El protocolo de bit alternante es igual que el protocolo GBN pero con un tamaño de ventana en el emisor y en el receptor igual a 1. R/: Verdadero. Tenga en cuenta que con un tamaño de ventana de 1, SR, GBN, y el protocolo bit alterno son funcionalmente equivalentes. El tamaño de la ventana de 1 excluye la posibilidad de paquetes fuera de orden (dentro de la ventana). Un  ACK acumulativo es sólo un ACK ordinario en esta situación, ya que sólo puede referirse al solo paquete dentro de la ventana. 23. 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? R/: Considere la posibilidad de enviar un mensaje de aplicación durante un protocolo de transporte. Con TCP, la aplicación escribe datos en la conexión de envío de búfer y TCP se agarra bytes sin poner necesariamente un único mensaje en el segmento TCP; TCP puede poner más o menos un solo mensaje en un segmento. UDP, por otro lado, encapsula en un segmento cualquiera que sea la aplicación, de modo que, si la aplicación da UDP en un mensaje de aplicación, este mensaje será la carga útil del segmento UDP. Así, con UDP, una aplicación tiene más control de lo que los datos envían en un segmento.

b. ¿Por qué una aplicación tiene más control sobre cuándo se envía el segmento?

R/: Con TCP, debido al control de flujo y control de congestión, puede haber un retraso significativo desde el momento cuando una aplicación escribe datos en su búfer de envío hasta que cuando los datos se da a la capa de red. UDP no tiene retrasos debido al control de flujo y control de congestión. 24. Se desea transferir un archivo de gran tamaño de L bytes del host A al host B. Suponga un MSS de 536 bytes. Hay 2^32= 4294967296 posibles números de secuencia. 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. R/: El número de secuencia no se incrementa en 1 con cada segmento. Más bien, se incrementa por el número de bytes de datos enviados. Así que el tamaño de la MSS es irrelevante, el tamaño de archivo máximo que se puede enviar de A a B es simplemente el número de bytes que puede representarse por 2^32 = 4.19 Gbytes 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 congestión de modo que A pueda bombear los segmentos seguidos y de forma continuada. R/: El número de segmentos es 2^32 / 536 = 8,012.998.687 * 66 bytes de cabecera, se añaden a cada segmento con un total de 528857934 bytes de cabecera. El número total de bytes transmitidos es 2^32 + 528857934 = 4823825230 bytes. Por lo tanto se necesitarían 249 segundos para transmitir el archivo a través de un enlace de 155 Mbps 25. 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, 70 y 50 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? R/: En el segundo segmento del host A al B, el número de secuencia es 197, 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 segmento, ¿cuál es el número de reconocimiento, el número del puerto de origen y el número del puerto de destino en el ACK correspondiente al primer segmento? R/: Si el primer segmento llega antes de la segunda, en el a cuse de recibo del primer segmento es 197, 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 primero, ¿cuál es el número de reconocimiento en el ACK correspondiente al primer segmento? R/: Si el segundo segmento llega antes de que el primer segmento, en el acuse de recibo del primer segmento de llegar, “el número de acuse de recibo es 127”, lo que indica que todavía está esperando para los bytes 127 y en adelante. 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 reconocimiento. R/.

26. Los hosts A y 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á transfiriendo al host B una 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 sólo puede leer los datos almacenados en su buffer de recepción TCP a una velocidad máxima de 60 Mbps. Describa el efecto del control de flujo de TCP.

R/: Dado que la capacidad de enlace se encuentra a 100 Mbps, por lo que la tasa de envío de host A puede ser en la mayoría de 100Mbps. Aun así, el host A envía datos en el búfer de recepción más rápido que el host B, por lo tanto puede eliminar datos de la memoria intermedia. El búfer de recepción se llena a un ritmo de aproximadamente 40 Mbps. Cuando el buffer está lleno, las señales Host B al Host  A detienen el envío de datos estableciendo Rcv Window = 0. Host A continuación, se detiene el envío hasta que reciba un segmento TCP con Rcv Window> 0. Anfitrión  A será de este modo detener y comenzar a enviar en función del Rcv Window valores que recibe del anfitrión B. En promedio, la tasa de largo plazo en la que el host A envía datos al host B como parte de esta relación no es más que 60Mbps repetidamente.

27. 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 SYN ACK? R/: El servidor utiliza el número de secuencia inicial especial (que se obtiene a partir del hash de IP y puertos de origen y de destino) con el fin de defenderse contra ataques SYN Flood. 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é? R/: No, el atacante no puede crear conexiones medio abiertas o completamente abiertas, simplemente enviando un ACK de paquetes a la meta. Las conexiones medio abiertas no son posibles desde un servidor utilizando los cookies, no mantiene las variables de conexión y tampoco para cualquier conexión antes de establecer conexiones completas. Para el establecimiento de conexiones totalmente abiertas, un atacante debe conocer el número de secuencia inicial especial correspondiente a la (falsa) de direcciones IP de origen del atacante. Este número de secuencia requiere el número "secreto" que utiliza cada servidor. Dado que el atacante no conoce este número secreto, ella no puede adivinar el número de secuencia inicial.

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é? R/: No, el servidor simplemente puede añadir un sello de tiempo en el cálculo de los números de secuencia inicial y elegir un tiempo de vida de valor para los números de secuencia, y deseche los números de secuencia iniciales caducadas incluso si el atacante quiere reproducirlos. 28. 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). R/: Si observamos los valores de tiempo de espera, entonces los remitentes pueden tener tiempo de espera antes de tiempo. Por lo tanto, algunos paquetes se retransmiten incluso que no se pierdan. b. Suponga ahora que ambos hosts ajustan dinámicamente su 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é? R/: Si los valores de tiempo de espera se estima (como lo hace TCP), a continuación, aumentar el tamaño del búfer sin duda ayuda a aumentar el rendimiento de ese router. Pero puede haber un problema potencial. Que un retraso podría ser muy grande, similar a lo que se muestra en el escenario 1. 29. Considere el procedimiento de TCP para estimar RTT. Suponga que = 0,1. Sea RTT Muestra 1 la muestra de RTT más reciente, RTT Muestra 2 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, RTT Muestra 4, RTT Muestra 3, RTT Muestra 2 y RTT Muestra 1. Exprese RTT Estimado en función de las cuatro muestras de RTT. b. Generalice la fórmula para n muestras de RTT. 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.

30. En la Sección 3.5.3, se ha estudiado la estimación de RTT en TCP. ¿Por qué cree que TCP evita medir RTT Muestra para los segmentos retransmitidos? R/: Si TCP mide RTT Muestra para un segmento retransmitido. Supongamos que la fuente envía paquetes P1, el temporizador expira para P1, y la fuente envía entonces P2, una nueva copia del mismo paquete. Supongamos, además, las medidas de origen RTT Muestra para P2 (el paquete retransmitido). Finalmente suponer que poco después de la transmisión de un acuse de recibo para P2 P1 llega. La fuente erróneamente tendrá este reconocimiento como un reconocimiento para P2 y calcular un valor incorrecto de RTT Muestra. 31. ¿Cuál es la relación entre la variable Enviar Base de la Sección 3.5.4 y la variable Ultimo Byte Recibido de la Sección 3.5.5? R/: En cualquier momento dado t, Enviar Base - 1 es el número de secuencia del último byte que el remitente sabe que se ha recibido correctamente, en el receptor. El último byte recibido realmente (correctamente y en orden) en el receptor en el momento t puede ser mayor si existen reconocimientos en el camino. Así Enviar Base-1 ≤ Último Byte Recibido. 32. ¿Cuál es la relación entre la variable Ultimo Byte Recibido de la Secc ión 3.5.5 y la variable y de la Sección 3.5.4? R/: Cuando en el tiempo t, el remitente recibe un acuse de recibo con el valor de y, el remitente sabe a ciencia cierta que el receptor ha recibido todo a través de y-1. El último byte real recibido (correctamente y en orden) e n el receptor en el momento t puede ser mayor si y ≤ Enviar Base o si hay otros reconocimientos en el camino.  Así y-1 ≤ Último Byte Recibido.

33. En la Sección 3.5.4 hemos visto que TCP espera hasta que ha r ecibido 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? R/: Supongamos que tenemos paquetes n, n +1 y n +2 se envían y se reciben ese paquete n y ACK. Si los paquetes n 1 y n 2 se reordenan a lo largo del trayecto de extremo a extremo (es decir, son recibidos en el orden n 2, n 1), entonces la recepción de paquetes n 2 generará un acuse de recibo por duplicado para n y daría lugar a una retransmisión en virtud de una política de espera sólo para segundo  ACK duplicado para la retransmisión. Esperando un ACK duplicado de triple, tiene

que ser el caso de que dos paquetes después de paquetes n están correctamente recibidos, mientras que n + 1 no fue recibido. Los diseñadores del esquema ACK duplicado triples probablemente sintieron que la espera de dos paquetes (en lugar de 1) era la disyuntiva entre la derecha que provocó una retransmisión rápida cuando sea necesario, pero no retransmitir prematuramente en la faz de la reordenación de paquetes. 34. 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 (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 cuantos ACK ha enviado en total el host B? ¿Cuáles son sus números de secuencia? Responda a esta pregunta para los tres protocolos. 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? 35. En la descripción de TCP de la Figura 3.53, el valor del umbral se define como umbral=Ventana Congestión/2 en varios sitios y el valor de umbral 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 Ventana Congestión 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 umbral? R/: Sí, la velocidad de envío es siempre más o menos cwnd / RTT 36. Considere la Figura 3.46 (b). Si ƛ in 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 ƛ in 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. R/: Si la tasa de llegada aumenta más allá de R / 2 en la Figura 3.46 (b), entonces la tasa total de llegada a la cola excede la capacidad de la cola, lo que resulta en el aumento de la pérdida como la tasa de llegada se incrementa. Cuando la tasa de llegada es igual a R / 2, 1 de cada tres paquetes que deja la cola es una retransmisión. Con el aumento de la pérdida, incluso una fracción más grande de

los paquetes que salen de la cola será retransmisiones. Dado que la tasa de salida máxima de la cola de una de las sesiones es de R / 2, y dado que un tercio o más habrá transmisiones como la tasa de llegada aumenta, el rendimiento de entregar con éxito los datos no pueden aumentar más allá λout. Siguiendo un razonamiento similar, si la mitad de los paquetes que salen de la cola son retransmisiones, y el porcentaje máximo de paquetes de salida por sesión es de R / 2, entonces el valor máximo de λout es (R / 2) / 2 o R / 4. 37. 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 el modo de arranque lento. R/: Arranque lento TCP está funcionando en los intervalos [1,6] y [23,26] b. Identifique los intervalos de tiempo cuando TCP está operando en el modo de evitación de la congestión. R/: Evitación de congestión TCP está funcionando en los intervalos [6,16] y [17,22] 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? R/: Después de la ronda de transmisión a 16, la pérd ida de paquetes es reconocido por un ACK duplicado triples. Si había un tiempo de espe ra, el tamaño de la ventana de congestión se habría reducido a 1.

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? R/: Después de la ronda de transmisión a 22, pérdida del segmento se detecta debido a tiempo de espera, y por lo tanto el tamaño de la ventana de congestión se establece en 1 e. ¿Cuál es el valor inicial de umbral en el primer ciclo de transmisión? R/: El umbral es inicialmente 32, ya que es en este tamaño de la ventana que arranque lento para y comienza evitación de la congestión. f. ¿Cuál es el valor de umbral transcurridos 18 ciclos de transmisión? R/: El umbral se fija a la mitad del valor de la ventana de congestión cuando se detecta la pérdida de paquetes, la transmisión ronda 16, el tamaño de las ventanas de congestión es de 42. De ahí que el umbral es 21 en la ronda de transmisión 18. g. ¿Cuál es el valor de umbral transcurridos 24 ciclos de transmisión? R/: 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 transmisión ronda 22, el tamaño de las ventanas de congestión es 26. De ahí que el umbral es 13 en la ronda de transmisión 24. h. ¿Durante cuál ciclo de transmisión se envía el segmento 70? R/: Durante la primera ronda de la transmisión, el paquete 1 es enviado ; paquetes 2-3 se envían en la segunda ronda de la transmisión ; 4-7 paquetes se envían en la tercera, la transmisión de todo el año; 8-15 paquetes se envían en el cuarta ronda de transmisión ; paquetes 16-31 son enviados en la quinta ronda de la transmisión ; 32-63 paquetes se envían en el sexta ronda de transmisión ; paquetes de 64 a 96 son enviados en la séptima ronda de transmisión . Así paquete 70 se envía en la séptima ronda de transmisión. i. Suponiendo que se detecta una pérdida de paquete después del ciclo de transmisión 26 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 umbral? R/: La ventana de congestión y el umbral se establecerán en la mitad del valor actual de la ventana de congestión (8) cuando se produjo la pérdida. Así, los nuevos valores de los umbrales y ventanas serán 4.

 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 umbral en el ciclo de transmisión 19? R/: El umbral es 21, y el tamaño de la ventana de congestión es 1 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? R/: Ronda 17, 1 paquete; ronda de 18, 2 paquetes; ronda 19, 4 paquetes; ronda 20, 8 paquetes; ronda 21, 16 paquetes; ronda de 22, 21 paquetes. Así, el número total es 52 38. Utilice la Figura 3.56, 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.56. 39. 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? R/: Si TCP fuera un protocolo de parada y espera, a continuación, la du plicación del tiempo de intervalo sería suficiente como mecanismo de control de congestión. Sin embargo, TCP utiliza revestimiento (y por lo tanto no es un protocolo de parada y espera), lo que permite al remitente que tiene múltiples segmentos no reconocidos pendientes. La duplicación del tiempo de desbordamiento no impide que un TCP remitente del envío de un gran número de paquetes de primera, el tiempo de transmisión en la red, incluso cuando la ruta de extremo a extremo está muy congestionada. Por lo tanto se necesita un mecanismo de control de congestión para detener el flujo de "datos recibidos de la aplicación anterior" cuando hay signos de congestión de la red. 40. 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 e l 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 sólo 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. R/: En este problema, no hay peligro de desborde del receptor desde el búfer de recepción del receptor puede almacenar todo el archivo. También, porque no hay pérdida y acuses de recibo se devuelven antes de que expiren los temporizadores, el control de congestión del TCP no estrangula el remitente. Sin embargo, el proceso en el host A no va a pasar de forma continua los datos a la toma de corriente porque el búfer de emisión, se agotará pronto. Una vez que el buffer de envío se llena, el proceso va a pasar datos a una tasa promedio o R = W / 2. Vamos Tp denotan el retardo de propagación de un solo sentido entre el emisor y el receptor. Cuando el tamaño de la ventana alcanza el mínimo W / 2 y el buffer se vacía, hay que asegurarse de que el enlace está también ocupado enviando datos. Por lo tanto, debemos tener W / 2 / (2TP)> = C, por lo tanto, W / 2> = C * 2TP. Por lo tanto, s> = C * 2TP. 45. Repita el Problema 43, 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. R/.  A) Sea W denota el tamaño máximo de la ventana. Entonces, W * MSS / RTT = 10 Gbps, ya que los paquetes se eliminará si la tasa máxima enviando alcanza la capacidad del enlace. Por lo tanto, tenemos W * 1500 * 8/0.1 = 10 * 10 ^ 9, entonces W = 83,334 segmentos.

B) Como tamaño de ventana de congestión varía de W / 2 a W, entonces el tamaño medio de la ventana es 0.75W = 62.501 segmentos. El rendimiento promedio es de 62501 * 1500 * 8/0.1 = 7.5Gbps.

C) 83334/2 * 0,1 / 60 = 69 minutos. Con el fin de acelerar el proceso de aumento de la ventana, podemos aumentar el tamaño de la ventana por un valor mucho más grande, en lugar de aumentar el tamaño de ventana sólo por uno en cada RTT. Se proponen algunos protocolos para resolver este problema, tales como TCP escalable o de alta TCP.

46. 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. R/. Como promedio el rendimiento de TCP B está dada por así que sabemos que,

1.22∗/∗ 1/ ∗/1.22 ∗ 2

B .RTT . .√L

Dado que entre dos pérdidas de paquetes consecutivos, hay paquetes de 1 / L enviado por el remitente TCP, por lo tanto *MSS/B Por lo tanto, nos encontramos con que que es, T es una función de B. 47. 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, C1 y C 2, comparten un enlace congestionado cuya velocidad es de 30 segmentos por segundo. Suponemos que tanto C1 como C2 están en l fase de evitación de la congestión. El intervalo RTT de la conexión C1 es igual a 100 milisegundos y el de la conexión C2 es igual a 200 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 t0 el tamaño de la ventana de congestión de ambas conexiones, C1 y C2, es de 10 segmentos, ¿cuáles serán los tamaños de

dichas ventanas de congestión después de transcurridos 2200 milisegundos? R/. La diferencia clave entre C1 y C2 es que RTT de C1 es sólo la mitad de la de C2. Así C1 ajusta su tamaño de la ventana después de 100 mlseg, pero C2 ajusta su tamaño de la ventana después de 200 mlseg. Supongamos que cada vez que un evento de pérdida ocurre, C1 recibe después de 100 ms y C2 recibe después de 200 milisegundos.  Además tenemos el siguiente modelo simplificado de TCP. Después de cada RTT, una conexión determina si se debe aumentar el tamaño de la ventana o no. Para C1, calculamos la tasa media total de envío en el enlace en los 100 ms previos. Si esa tasa supera la capacidad del enlace, entonces suponemos que C1 detecta la pérdida y reduce su tamaño de la ventana. Pero para C2, calculamos la tasa media total de enviar el enlace de la 200mseg anterior. Si esa tasa superior a la capacidad de enlace, entonces suponemos que C2 detecta la pérdida y reduce su tamaño de la ventana. Tenga en cuenta que es posible que el promedio de tasa de envío de 100 mseg en la última es mayor que la capacidad del enlace, pero el promedio de tasa de envío en la última de 200 milisegundos es menor que o igual a la capacidad del enlace, a continuación, en este caso, se supone que va a experimentar la pérdida de C1 evento, pero C2 no. En la siguiente tabla se describe la evolución de los tamaños de las ventanas y las tasas de envío basados en los supuestos anteriores.

C1

C2 promedio de tasa de

Tamaño de ventana (num. De

promedio de tasa de

envio de datos

envio de datos Tamaño de ventana (num. De

Time (msec)

segmentos enviados mayores a

(segmentos por

100msec)

segundo,

(segmentos por segundo,

=ventana/0.2)

=ventana/0.2)

segmentos enviados mayores a 200msec)

0

10

100 (en [0-100]msec]

10

50 (en [0-100]msec)

5

(disminuye el promedio del 100

50 (en [100-

50 (en [100-

200]msec]

200]msec)

tamaño de ventana. tasa de envío total para el enlace menor a 100 ms 150= 100+50)

2

5

(disminuye el promedio del (disminuye el promedio del tamaño de tamaño de ventana. Tasa de ventana. tasa de envío total para el 200

envío total para el enlace

20

25 enlace menor a 200msec is

menor a 100msec is 100= 125=(100+50)/2 + (50+50)/2) 50+50)

1 (disminuye el promedio del tamaño de ventana. Tasa de 300

10

25

envío total para el enlace menor at 100msec is 45= (20+25) 1

2 (disminuye el promedio del tamaño de

400

(no disminuye mas, el tamaño

10

de la ventana ya es 1)

ventana. Tasa de envío total para el

10

enlace menor a 200msec is 40= (20+10)/2 + (25+25)/2)

500

2

20

600

3

30

700

1

10

800

2

20

900

3

30

1

10 3

15 15

1

5 5

2

(disminuye el promedio del tamaño de ventana. Tasa de 1000

envío total para el enlace

(incrementa el promedio del tamaño de 10

ventana. Tasa de envío total para el

menor a 100msec is 35=

enlace menor a 200msec is 30=

(30+5)

(20+30)/2 + (5+5)/2)

1100

2

20

1200

3

30

1300

1

10

1400

2

20

1500

3

30

1600

1

10

1700

2

20

1800

3

30

1900

1

10

2000

2

20

2100

3

30

2200

1

10

10

10 3

15 15

1

5 5

2

10 10

3

15 15

1

5

2

10

5

b. ¿Obtendrán estas dos conexiones, a largo plazo, la misma cuota de ancho de banda del enlace congestionado? Explique su respuesta. 48. Continúe con la red descrita en el problema anterior, pero ahora suponga que las dos conexiones TCP, C1 y C2, tienen el mismo intervalo RTT de 100 milisegundos. Suponga que en el instante t0, el tamaño de la ventana de congestión de C1 es de 15 segmentos pero el tamaño de la ventana de congestión de C2 es igual a 10 segmentos. a. ¿Cuáles serán los tamaños de las ventanas de congestión después de transcurridos 2200 milisegundos? R/. Del mismo modo que en el último problema, podemos calcular sus tamaños de ventana en el tiempo en el siguiente tabla. Tanto C1 y C2 tienen el mismo tamaño de la ventana 2 después de 2200msec.

C1

C2

Tamaño de Velocidad de Tamaño de Velocidad de venta datos enviados ventana datos enviados (num. De (num. De Tiempo (msec) segmentos segmentos enviados (segmentos enviados (segmentos mayores a 100 por segundo = mayores a 100 por segundo = msec) ventana/0.1) msec) ventana/0.1) 0

15

150 (en [0100lmsec]

10

100 (en [01001 msec)

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? R/. Sí, esto se debe a que el algoritmo AIMD de TCP. Y que ambas conexiones 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? R/. Sí, esto se puede ver claramente a partir de la tabla anterior. Su tamaño máximo de la 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. R/. No, esta sincronización no va a ayudar a mejorar la utilización del enlace, ya que estas dos conexiones actúan como un único oscilante conexión entre min y max tamaño de ventana. Por lo tanto, el vínculo no se utiliza plenamente (recordemos que asumir este enlace no tiene ningún buffer). Una forma posible de romper la sincronización es añadir un tampón finito al enlace y colocar aleatoriamente paquetes en el búfer antes del desbordamiento de búfer. Esto causará diferentes conexiones para reducir sus tamaños de ventana en diferentes momentos. Hay muchas técn icas para hacer eso como: AQM (Active Queue Management), RED (Random Early Detect), PI (Proportional and Integral AQM), AVQ (Adaptive Virtual Queue) y REM (Random exponential Marking), etc 49. 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 a (0 < a < 1) cuando recibe un ACK válido. Halle la relación funcional existente entre la tasa de pérdidas L y el tamaño máximo de la ventana de congestión W. 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 W/2a W. R/. Tenga en cuenta que W representa el tamaño máximo de la ventana. En primer lugar se encuentra el número total de segmentos enviados durante el intervalo en TCP cambia su tamaño de la ventana de W / 2 hasta e incluir W. Esto viene dado por:

S = W / 2 + (W / 2) * (1 + α) + (W / 2) * (1 + α)2 + (W / 2) * (1 + α)3 +... + (W / 2) * (1 + α)k Nos encontramos con k = log (1 + α)2, entonces S = W * (2α +1) / (2α). Tasa de pérdida de L está dada por: L = 1 / S = (2α) / (W * (2α 1)). El tiempo que toma TCP para aumentar su tamaño de la ventana de W / 2 a W está dada por: k* RTT = (log (1 + α) 2) * RTT, que es claramente independiente del rendimiento medio de TCP. Tenga en cuenta, el rendimiento promedio de TCP está dado por: B = MSS * S / ((k +1) * RTT) = MSS / (L * (k +1) * RTT). Tenga en cuenta que esto es diferente de TCP que tiene rendimiento promedio:

 .RTT.∗√ 

B

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

50. 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 sólo podría tolerar una probabilidad de pérdida de segmentos de 2 · 10^-10 (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 2 · 10^-10 y 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? R/. Supongamos que los paquetes de 1500 bytes y un tiempo de ida y vuelta de 100 ms. Desde el rendimiento de TCP la ecuación es: y tenemos

51. 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 t 1 se queda inactiva (puesto que no tiene más datos que enviar). TCP permanece inactivo durante un periodo de tiempo relativamente largo y en el instante t2 quiere enviar más datos. ¿Cuáles son las ventajas y las desventajas de que TCP tengan que utilizar los valores de Ventana Congestión y umbral de t 1 cuando comienza a enviar datos en el instante t2? ¿Qué alternativa recomendaría? ¿Por qué? R/. Una ventaja de utilizar los valores anteriores de cwnd y ssthresh en el instante t2 es que TCP haría un comienzo lento para no tener que ir a través de la congestión de la rampa hasta el rendimiento del valor obtenido en el instante t1. Una desventaja del uso de estos valores es que pueden ser poco exactos. En particular, si la ruta

de acceso se ha vuelto congestionada entre t1 y t2, el remitente envía el valor del segmento en una gran ventana de un camino ya (más) congestionado. 52. En este problema vamos a investigar si UDP o TCP proporcion an 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? R/. 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 ser vidor estar seguro de que el cliente está en la dirección Y (y no en alguna otra d irección X que esté intentando suplantar a Y)? R/. El servidor puede estar seguro de que el cliente es de hecho Y. Si fuera algún otro domicilio erróneo Y, el SYNACK habría sido enviado a la dirección Y, y el TCP en ese anfitrión no enviaría el segmento TCP ACK de vuelta. Incluso si el atacante enviara debidamente un segmento TCP ACK, no sabría la secuencia correcta del número de servidor (ya que el servidor utiliza números de secuencia iniciales aleatorias.)

53. 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 > 2S/R R/.

View more...

Comments

Copyright ©2017 KUPDF Inc.
SUPPORT KUPDF