Apunte de Clase del 23/10/2007 (Teoría de las Comunicaciones)
TCP[editar]
- Protocolo end-to-end
- Confiable
- Reliable byte-stream
- Orientado a conexión
- Control de flujo
- Full duplex
- Control de congestión
A este nivel lo único que hacemos es lectura y escritura de a byte.
Pregunta: Qué campo en el header de TCP da la pauta de que es full-duplex? El ACK, porque en vez de mandar un paquete entero con el ACK hace el piggyBacking y reusa un paquete de datos.
3 Fases porque es orientado a conexión:
- Establecimiento de la conexión
- Transferencia de los datos
- Liberación de la conexión
Sliding Window en TCP[editar]
Ack acumulativo, no es selectivo. Eso no lo hace muy eficiente, pero lo inventaron así, lola.
En n2, protocolos de ventana deslizante, hay un timeout. En n2 el timout era constante, ya que el delay es conocido.
INCOMPLETAL: Este protocolo en n2 es de de tipo lazo abierto o de lazo cerrado
En TCP, el RTT es constante en función del tiempo o del nro de paquete IP? Noooooooo!! Pero entonces, si la demora en llegar un ack es tan variable, puedo definir un timeout constante? Si se eligiera muy grande quizás funcionaria, pero sería una porquería. Qué hago entonces? Ponderamos por RTT, y en función de ese valor estimamos el timeout de retransmisión. Yo voy a accionar mi sistema (ajusta el timeout de transmisión) del valor ponderado. Esto permite evitar que el sistema oscile a lo loco. Se puede hacer un promedio ponderado muy sencillo o también cosas más complicadas.
EstimatedRTT_i+1 = (a - alpha) * EstimatedRTT_i + alpha * SampleRTT_i+1
Este tipo de fórmulas se donominan promedio móvil y además se dice que la influencia de las muestras anteriores es exponencialmente menor. Si alpha es muy chico tiende a ser muy estable, si alpha es muy grande puede verse muy afectado por valores anteriores.
El TimeOut se fija entonces en TimeoutInterval = 2 * EstimatedRTT_i+1
Utilizando el desvio estándar del RTT se puede ajustar el timeout de retransmisión sin caer en falsos timeout, tomando:
TimeoutInterval = EstimatedRTT + 4 * DevRTT
.
Threeway handshake (establecimiento de la conexión)[editar]
[ver resumen del cap 5 del peterson, o completar acá con info del Peterson o cualquier otra fuente]
Se marca que un segmento es sync con el flag de sync.
Eddy hace preguntas estúpidas: cuál es la traducción de allocate?
Porqué es necesaria una alocación de recursos? Porque usa ventana deslizantes, porque tengo que tener un espacio de buffer necesario para determinado valor de timeout.
Nota: Morrison detectó problemas del protocolo que explotan el denial of service (no mandando el segmento del tercer paso del protocolo). Buscar en la wikipedia, en clase se explicó un poco del tema.
righetti boludea a Luigi
Liberación de la conexión[editar]
Hay que liberar muchos recursos involucrados. Para eso se utiliza un doble handshake.
- --> Envio FIN
- <-- ACK
- <-- otro FIN
- --> y ACK de vuelta
Puedo hacer un protocolo para sincronizar dos procesos en un canal no confiable y que permita que estos dos procesos sincronicen para hacer algo al mismo tiempo (ej, apagarse). Este es el "problema de los dos ejércitos"y no tiene solución (en el tanembaum, se lo menciona). Un paliativo ingenieril es poner un timeout desde que llega el segundo FIN y considerar que la conexión fue cerrada si pasado ese tiempo no llegó el ACK.
pREGUNTA de parcial: Porqué hay un wait2 después de un wait1 en la maquina de estados de TCP? que
El timeout en TCP es 2*MSL: Maximum segment life
Importante: Puede haber una ambiguedad en la transmisión. debo tomar como muestra del RTT el tiempo que tarda en llegar el ack luego de una retransmisión? No, porque no sé si ese ack corresponde a la transmisión original o a la retransmisión (recordar que ambos tienen el mismo nro de secuencia), ergo, se ignora la muestra en la estimación del RTT cuando hubo retransmisión.
Data Link VS Transport: - Potencialmente muchos hosts (por eso conexiones explícitas) - Por culpa de la multiplexación a través de los puertos puede haber RTT muy dispares. Para eso se usa un timeout ponderado. [esto está en la sección End To End issues en el cap 5 del Peterson, en la primera parte]. - Diferentes capacidades en los destinos y dentro de la red (lleva a congestión)
porqué Peterson no hace hincapié en el ordenamiento de paquetes? Porque antes se pensaba que el ordenamiento de paquetes era un fenómeno que se producía poco y no afectaba mucho el funcionamiento. Recién ahora se está tomando más en cuenta ya que se ha observado que parece afectar bastante y en las wireless se da más seguido. CHECK: en las primeras versiones de TCP no se hacía nada con el desordenamiento (era responsabilidad de la aplicación).
El software TCP/UDP arma un pseudoheader que no se transmite a ningun lado y que se usa a los solos efectos del cómputo del checksum y que se hace copiando datos del header ip.
El aviso de ventana en cero es para hacer control de flujo y marcar que el emisor deje de mandar.
Deja pregunta: Ver cómo se selecciona el nro de secuencia inicial. ¿empiezo en cero?
SYN+ACK (gráfico de establecimiento de conexión): Significa que el flag de ack está en 1 y también el de SYN
Tara: Porqué algunos son pasivos y otros activos en el estableciemiento de la conexión? Righetti: Cazá el libro, velo por tu cuenta, la semana que viene nos va a preguntar.
Analizamos diagrama de estados del peterson, ese que es un quilombo TCP Options: Este campo permite aumentar o hacer un escalamiento del aviso de ventana. Se puede mostrar que en un protocolo de ventana deslizante el throutput es aproximadamente (hace hincapié en este punto):
tamaño de ventana / RTT
Entonces, cuando hay mucho RTT, se aumenta el tamanio de la ventana para aumentar intentar aumentar el throughput.
Cuenta de vuelta la historia del tipo que se queja de que contrató una CX de 1mb y su conexión a miami no alcanza el throughput que quiere. El operario le hace abrir 5 cx para taparle la boca
LEER LA BIBLIOGRAFÍA QUE MANDÓ POR MAIL. FUE MUY CLARO, SI LO MANDÓ ES POR ALGO. LEANLO.
