1 # Guia 2: Nivel de Transporte 2 3 Redes de Comunicaciones (TB067) - 2C2024 - FIUBA 4 Martin Klöckner - [mklockner@fi.uba.ar](mailto:mklockner@fi.uba.ar) 5 6 > 1. ¿Cómo se puede distinguir a qué aplicación debe entregar UDP el datagrama 7 > que acaba de llegar? 8 9 Se puede distinguir mediante el número de puerto especificado en la sección 10 `puerto de destino` del encabezado UDP. 11 12 > 2. ¿Cómo se calcula el checksum de UDP? 13 14 El checksum sirve para detectar si los datos contenidos en el encabezados UDP 15 han sido alterados mientras se trasladaban desde el origen al destino. 16 17 En el lado del emisor se calcula el complemento a 1 de la suma de todas las 18 palabras de 16 bits del segmento, en el caso de haber desbordamiento en la suma 19 se acarrea sobre el bit de menor peso. 20 21 En el receptor, se suman todas las palabras de 16 bits de la sección de datos 22 del encabezado, incluyendo el checksum, en caso de no haber errores el resultado 23 debe ser una palabra de 16 bits cuyos bits son todos 1; en caso de haber al 24 menos un 0, entonces ocurrió un error durante la transmisión. 25 26 > 3. Suponga que la ventana de congestión de TCP está en 18 Kbytes. La ventana 27 > publicada por el otro extremo de la sesión es de 64 Kbytes. ¿A qué valor 28 > llegará dicha ventana si los siguientes 5 segmentos transmitidos resultan 29 > exitosos y no se recibió aún ningún ACK? Suponga un tamaño máximo de 30 > segmento de 2 Kbytes. 31 32 La ventana de congestión indica la cantidad de bytes que pueden estar en la 33 linea ("on the wire") sin ser validados, suponiendo que el extremo que transmite 34 es el que tiene la ventana de 18 Kbytes, y la linea que recibe tiene una ventana 35 de 64 Kbytes, entonces si se envían los 5 segmentos y aun no han sido validados 36 la ventana de congestión del transmisor deber ser de 8 Kbytes, ya que es el 37 resultado de restar a la cantidad de bytes de la ventana de congestion del 38 transmisor la cantidad de datos en la linea. 39 40 > 4. Determine el tamaño óptimo de ventana para una sesión TCP en la que el 41 > RTT es `100 ms`, el MSS es `600 bytes` y la velocidad de la interfaz de 42 > `128 Kbps`. 43 44 El tamaño optimo de ventana se puede calcular utilizando la siguiente ecuación: 45 46 \vspace{-0.5em} 47 $$\text{Tamaño Optimo de Ventana}\ = \text{Velocidad de Interfaz} \cdot RTT$$ 48 49 Reemplazando con los valores de enunciado resulta: 50 51 $$\text{Tamaño Optimo de Ventana} = 100 Kbps\cdot 100 ms = 100000\ \nicefrac{bytes}{s}\cdot 0.100s \Rightarrow\boxed{100\ bytes}$$ 52 53 <!-- $$MTU = MSS + encabezado TCP e IP$$ 54 Si supera el MSS se descarta en cambio si supera el MTU se fragmenta 55 --> 56 57 > 5. Dos Hosts A y B se comunican a través de una sesión TCP. El host B recibió 58 > de A todos los bytes hasta el 144. Suponga que el Host A luego envía dos 59 > segmentos a B, de 20 y 40 bytes respectivamente. En el primer segmento el 60 > número de secuencia es 145, port origen 303 y port destino 80. El Host B 61 > envía un ACK siempre que recibe un segmento de A. Responda para cada 62 > situación: 63 > 64 > a. ¿Cuál será el número de secuencia, el número de ACK, y ports origen y 65 > destino en el segmento enviado por B al recibir el segmento de 40 bytes? 66 > b. Si el segmento de 40 bytes llega antes que el de 20 bytes, indique 67 > campos relevantes del segmento que B enviará. 68 > c. Suponga que los dos segmentos enviados por A llegan a B en orden. El 69 > primer ACK se pierde y el segundo segmento llega después que el timeout 70 > del primer segmento expire. Indique los segmentos a intercambiar por 71 > parte de A y B a continuación. 72 73 a. Suponiendo números de secuencia y reconocimiento relativos al comienzo de la 74 sesión; y teniendo en cuenta que el numero de secuencia de A es 145, entonces 75 luego de enviar los bytes a B, el numero de secuencia de A será 205, ya que 76 envía un total de 60 bytes, cuando B recibe estos datos debe responder 77 validando la recepción con un segmento ACK, como suponemos números de 78 secuencia y reconocimiento relativos, el numero de reconocimiento con el que 79 responde B debe coincidir con el numero de secuencia de los segmentos 80 enviados por A, por lo que deben ser 165 y 205 para el primer y segundo 81 paquete respectivamente (suponiendo que llegan en orden). Los puertos de 82 origen y destino se invierten ya que los segmentos van en el sentido 83 contrario del host B al A, por tanto resultan origen 80 y destino 303. 84 Finalmente, el numero de secuencia de B debería ser 1, el mismo que luego de 85 iniciada la sesión TCP ya que el host B no le envía datos a A, solo valida 86 los segmentos que A le envía. 87 b. Si el segmento de 40 bytes llega primero, el numero de reconocimiento del 88 host B y el numero de secuencia del paquete recibido de 40 bytes no 89 coinciden; el numero de reconocimiento de B sería 145 mientras que el numero 90 de secuencia del paquete es 165, es decir, falta llegar un paquete de 20 91 bytes. Ante esta situación puede ocurrir que el host B descarte el paquete de 92 40 bytes o que lo guarde en un buffer hasta recibir el segmento faltante, 93 esto depende de como esté configurado el stack TCP/IP en el host B. 94 c. Luego de que el timeout expira en el host A, este retransmite el segmento, 95 en el host B el segmento ya se había recibido dicho segmento por lo que se 96 descarta pero se vuelve a enviar el segmento ACK al host A. 97 98 > 6. En la secuencia de envío de segmentos TCP reflejada en la figura, en la que 99 > las líneas horizontales representan tics de reloj, se sabe que: 100 > 101 > * A desea enviar a B 200 bytes de datos. 102 > * B desea enviar a A 100 bytes de datos. 103 > * A y B usan un tamaño fijo de datos de 50 bytes. 104 > * A y B ajustan la ventana acorde con “congestion avoidance”. 105 > * Tanto A como B sólo transmiten segmentos coincidiendo con el tic de 106 > reloj. 107 > * Todos los segmentos tardan en llegar al destino medio tic de reloj, sino 108 > se pierden. 109 > * A y B tienen un plazo para retransmitir segmentos de 5 tics de reloj. 110 > * A y B enviarán segmentos con datos siempre que puedan. 111 > * A y B enviarán un asentimiento cada vez que reciban un segmento con 112 > datos. 113 > 114 > Teniendo en cuenta que la zona sombreada indica un periodo de tiempo 115 > durante el cual todos los segmentos transmitidos se perderán y que fuera 116 > de dicho periodo no se perderá ningún segmento, complete la transmisión 117 > en la figura (incluyendo el cierre de conexión). 118 > 119 > { width=75% } 120 > 121 > \vspace{-2.75em} 122 123 Luego de iniciar la conexión exitosamente, se comienza a transmitir los datos en 124 ambas direcciones, del host A al host B y viceversa; por enunciado se pierde el 125 primer paquete de la transmisión en ambos sentidos, esto provoca que luego de 5 126 ticks se retransmitan ambos segmentos, luego de 5 ticks ya no hay perdida de 127 paquetes y los datos llegan exitosamente. 128 129  130 131 \pagebreak 132 > 7. Complete la secuencia de envío de segmentos TCP reflejada en la figura, 133 > incluyendo el cierre de la conexión, en la que las líneas horizontales 134 > representan tics de reloj, sabiendo que: 135 > 136 > * No se perderá ningún segmento en la transmisión excepto el cuarto con 137 > datos enviados por A. 138 > * Los segmentos no dibujados (excepto el anteriormente citado) tardarán en 139 > llegar al destino medio tic de reloj, y no se perderán. 140 > * A está utilizando arranque lento (Slow Start) para prevenir la 141 congestión. 142 > * A tiene que enviar a B 800 bytes de datos, una vez enviados procederá 143 > a cerrar la conexión. 144 > * B no desea enviar datos a A. 145 > * B enviará asentimientos a A cuando haya recibido dos segmentos de A desde 146 > el último segmento asentido o cuando hayan sucedido 2 tics de reloj desde 147 > el último segmento recibido. 148 > * El plazo de retransmisión de segmentos en A (timeout) es de 3 tics de 149 > reloj. 150 > * A usa un tamaño fijo de datos de 200 bytes 151 > * B siempre enviará un valor de 800 en el campo de tamaño de la ventana de 152 > recepción. 153 > * Tanto A como B sólo transmiten segmentos coincidiendo con el tic de 154 > reloj. 155 > * A enviará segmentos con datos siempre que pueda. 156 > 157 > { width=75% } 158 > 159 > \vspace{-2.75em} 160 161 <!-- 162 Teniendo en cuenta que el MSS es de 200 bytes, y que la transmisión de datos 163 comienza en arranque lento, el tamaño de ventana de congestión del emisor se 164 establece en 1 MSS, por lo que luego de establecido el inicio de sesión el 165 emisor envía 1 segmento TCP con 200 bytes de datos 166 --> 167 168 En el caso de que no se pierda ningún paquete, la transmisión de datos del host 169 A al host B es la que se muestra en la figura a continuacion, se puede ver que 170 luego de iniciada la sesion el host A comienza a enviar los datos duplicando la 171 cantidad de datos enviados en cada segmento ACK que llega. 172 173 Como por enunciado se pierde el ultimo segmento de datos enviado por el host 174 A, la diferencia con la figura que se verá será que luego de pasados 3 ticks 175 de reloj de no recibir el segmento de validación de este ultimo segmento enviado 176 por parte del host B, el host A lo retransmitirá con el mismo número de 177 secuencia: `1601`. 178 179 { width=90% } 180 181 \pagebreak 182 > 8. Se realizó la captura de las siguientes tramas Ethernet: (tenga en cuenta 183 > que se extrajeron los bytes de preámbulo) 184 > 185 > \captionsetup[subfigure]{labelformat=empty} 186 > { width=48% } 187 > \hspace{0.5em} 188 > { width=48% } 189 > \vspace{-1.00em} 190 > \begin{figure}[H] 191 > \begin{subfigure}[t]{0.50\textwidth} 192 > \caption{Trama 1} 193 > \end{subfigure} 194 > \hfill 195 > \begin{subfigure}[t]{0.478\textwidth} 196 > \caption{Trama 2} 197 > \end{subfigure} 198 > \end{figure} 199 > 200 > { width=48% } 201 > \hspace{0.5em} 202 > { width=48% } 203 > \vspace{-1.00em} 204 > \begin{figure}[H] 205 > \begin{subfigure}[t]{0.50\textwidth} 206 > \caption{Trama 3} 207 > \end{subfigure} 208 > \hfill 209 > \begin{subfigure}[t]{0.478\textwidth} 210 > \caption{Trama 4} 211 > \end{subfigure} 212 > \end{figure} 213 > 214 > { width=48% } 215 > \hspace{0.5em} 216 > { width=48% } 217 > \vspace{-1.00em} 218 > \begin{figure}[H] 219 > \begin{subfigure}[t]{0.50\textwidth} 220 > \caption{Trama 5} 221 > \end{subfigure} 222 > \hfill 223 > \begin{subfigure}[t]{0.478\textwidth} 224 > \caption{Trama 6} 225 > \end{subfigure} 226 > \end{figure} 227 > 228 > Se pide: Analizar los campos relevantes de la información de nivel de 229 > transporte que contienen. 230 231 Analizando el encabezado Ethernet de todas las tramas (bytes en verde) se puede 232 ver que en todas se utiliza el protocolo de red IPv4, ya que en el ultimo par de 233 bytes se encuentra `0x0800`. 234 235 Del encabezado IPv4 (bytes en rojo) se puede ver que el protocolo utilizado en 236 las tramas 1 y 2 es UDP, ya que en el décimo byte se encuentra `0x11` (en 237 decimal `17`), el cual es el numero correspondiente con ese protocolo. 238 239 \vspace{1em} 240 \renewcommand{\arraystretch}{1.25} 241 \begin{tabularx}{1.00\textwidth} { 242 | >{\centering\arraybackslash}X 243 | >{\centering\arraybackslash}X 244 | >{\centering\arraybackslash}X 245 | >{\centering\arraybackslash}X 246 | >{\centering\arraybackslash}X | } 247 \hline 248 Trama & Src Port & Dest Port & Length & Checksum \\ \hline 249 1 & 1030 & 53 & 42 & 11432 \\ \hline 250 2 & 53 & 1030 & 72 & 13845 \\ \hline 251 \end{tabularx} 252 \vspace{1em} 253 254 Para las tramas restantes: 3, 4, 5 y 6, el protocolo es TCP, ya que en lugar de 255 encontrarse `0x11` se encuentra `0x6` (`6` en decimal) el cual corresponde con 256 este protocolo. 257 258 \vspace{1em} 259 \renewcommand{\arraystretch}{1.25} 260 \begin{tabularx}{1.00\textwidth} { 261 | >{\centering\arraybackslash}X 262 | >{\centering\arraybackslash}X 263 | >{\centering\arraybackslash}X 264 | >{\centering\arraybackslash}X 265 | >{\centering\arraybackslash}X 266 | >{\centering\arraybackslash}X 267 | >{\centering\arraybackslash}X | } 268 \hline 269 \small 270 Trama & Src Port & Dest Port & Seq \# & Ack \# & Win Size & Flags \\ \hline 271 3 & 3156 & 80 & 4041778071 & 0 & 65535 & SYN \\ \hline 272 4 & 80 & 3156 & 373009933 & 4041778072 & 5840 & SYN, ACK \\ \hline 273 5 & 3156 & 80 & 4041778072 & 373009934 & 65535 & ACK \\ \hline 274 6 & 3156 & 80 & 4041778072 & 373009934 & 65535 & PSH, ACK \\ \hline 275 \end{tabularx} 276 \vspace{1em} 277 278 > 9. ¿Qué son Slow Start y Congestion Avoidance? ¿Cómo intervienen sobre el 279 tráfico? 280 281 Arranque lento (Slow Start) y Evitación de Congestión (Congestion Avoidance) son 282 dos mecanismo que utiliza TCP para evitar la congestion en la linea al 283 transmitir datos. Para evitar la congestion en la linea, se limita la cantidad 284 de bytes que el emisor puede enviar sin ser validados por el receptor. Esta 285 magnitud que define la cantidad de bytes en la linea sin ser reconocidos, se 286 almacena en el emisor como **ventana de congestion**. 287 288 Cuando se establece una sesión TCP, la ventana de congestion del emisor se 289 establece en `1 MSS` y se incrementa de acuerdo al mecanismo de Arranque lento, 290 en el cual se duplica por cada segmento ACK recibido, esto provoca que la 291 ventana de congestion crezca exponencialmente en cada periodo RTT hasta que se 292 produzca congestion en la red, detectado por ejemplo por la perdida de un 293 paquete (el cual luego se retransmite), luego de que se detecte la congestion la 294 ventana de congestion vuelve a un valor pequeño como `1 MSS` y se define un 295 umbral, el cual queda determinado por la mitad del valor de la ventana de 296 congestion cuando se produzco la congestion; el valor de la ventana de 297 congestión vuelve a incrementar exponencialmente pero esta vez hasta el valor 298 umbral desde donde luego se cambia el mecanismo a evitación de la congestion, en 299 el cual la ventana de congestion se incrementa linealmente en `1 MSS` por cada 300 RTT. El mecanismo de arranque lento también puede terminar si se detecta 3 301 paquetes ACK duplicados, en cuyo caso TCP realiza una retransmisión rápida. 302 303 En el modo de evitación de la congestión, el valor de la ventana de recepción es 304 aproximadamente la mitad del valor que tuvo en la transmisión anterior en la 305 cual hubo congestion, en este modo la ventana de congestion se incrementa 306 linealmente y se termina en los mismo caso que para arranque lento.
