TCP TCP - Flujo de Datos Interactivo En login remoto el eco es remoto => Tx 1 char es intercambiar 4 segmentos Se observa del lado Server un ACK retardado en espera de datos. Se podrían combinar el 2º y el 3º. Concepto piggybacking: enviar datos + ACK. TCP - Flujo de Datos Interactivo. ACK´s retardados C S d ACK + eco d t ACKretardado< 200 ms ACK • Del lado servidor siempre habrá datos para Tx. De su lado, no se llega a retardar el ACK por que el timer no llega a expirar. a t entreACK= k x 200 ms ACK + eco a ACK • Timer de ACK Retardado: TCP espera hasta 200 ms antes de Tx el ACK. Si durante ese período hay datos para Tx, TCP los envía junto con el ACK (piggybacking) . Si no, se vence el timer y vemos ACK´s retardados (sin datos) en la red TCP - Flujo de Datos Interactivo. Algoritmo de Nagle Se idea para solucionar problema de tynigramas (1 byte de datos + 20 Header IP + 20 Header TCP) que pueden generar congestión o empeorarla si existe. Cuando una conexión tiene datos en el buffer de Tx esperando ACK, no puede Tx segmentos pequeños hasta que los datos no Rx ACK. De este modo, se juntan cierta cantidad de datos en un segmento y se Tx cuando se Rx el ACK. Genera concepto de selfclocking: cuanto más rápido llegan los ACK´s, más rápido se Tx los datos. Si observamos RTT en LAN: 1 ms => tipear 1 char/ 1 ms => tipear 1000 chars/seg => Nagle no se dispara. Para cuando baja el char al buffer ya llegó el ACK. Si observamos RTT en WAN: 1 seg => tipear 1 char/s => Hay mayor probabilidad de que Nagle se dispare => No se verían ACK´s retardados desde el C pues hay grandes probabilidades de tener datos listos a Tx antes que expire el timer de ACK. Generalmente los ACK´s retardados se reconocen por que no llevan datos. Desventaja: En caso de interactividad en tiempo real el Algoritmo de Nagle podría generar efectos molestos. TCP- Flujo de Datos Interactivo. Algoritmo de Nagle • Ejemplo de intercambio con Nagle: Se van juntando bytes en buffer: 1, 1, 2, 1, 2, 2, 3, 1 => 16 bytes en 9 segmentos en lugar de 16 segmentos. • El segmento 12 es una ACK retardado. • El segmento 18 no es el eco del 17, esto es una señal que TCP y la aplicación trabajan de manera independiente. Además el tamaño de la ventana es 2 bytes menor que en el segmento previo, indicando que no se ha subido a la aplicación. TCP - Flujo de Datos Interactivo. Algoritmo de Nagle TCP - Flujo de Datos Interactivo. Algoritmo de Nagle TCP - Flujo de Datos Interactivo. Sin Algoritmo de Nagle En este ejemplo se deshabilitó Nagle, viajan entonces los tres segmentos por separado. A partir de que se Tx el primer byte, no se espera ACK para Tx segundo y tercero. También acá se puede observar cómo actúa TCP cuando recibe segmentos fuera de orden y el concepto de repaquetización (por timeout y ReTx). En la cuarta línea el cliente recibe el Nº de secuencia 5 del servidor, pero esperaba el 2. Responde sin retardo con ACK 2 (duplicado) para indicar la llegada de datos fuera de orden. Cuando llega el Nº de secuencia que estaba esperando contiene los bytes 2 a 5 (ha habido un re-empaquetado de datos) TCP - Flujo de Datos Bulk TCP usa protocolo de Ventana Deslizante para control de flujo entre extremos. No se precisa reconocer cada segmento. El reconocimiento puede ser acumulativo. No existe una única manera de intercambiar información pues esto depende cuestiones relacionadas con el scheduling del SO (priorización de tareas), la dinámica de la red, etc. La diferencia entre la capacidad de procesamiento entre extremos de un intercambio se compensa con el anuncio de ventana. Puede llegar a anunciarse win = 0 para detener el flujo y luego actualizar el valor para retomarlo. TCP - Flujo de Datos Bulk. Ejemplo transferencia de 8192 bytes. Acumulativo TCP - Flujo de Datos Bulk. Ejemplo transferencia de 8192 bytes. Acumulativo Acumulativo TCP - Ventana de Transmisión Ha llegado ACK4 y win = 6. El tamaño de la ventana es relativo al Número de Secuencia del ACK. El Tx calcula su ventana útil (usable window), o sea cuántos datos podría Tx ahora. Observar el movimiento deslizante. Pueden llegar ACK´s duplicados (menores que 4) y no se tienen en cuenta. En TCP el tamaño máximo de win es 65.535 bytes. TCP - Ventana de Transmisión SND.UNA apunta al primer byte sin ACK e indica comienzo de Transmit Category #2; SND.NXT apunta al siguiente byte de datos a Tx e indica comienzo de Transmit Category #3. SND.WND contiene el tamaño de la ventana de Tx, se agrega a SND.UNA para marcar comienzo de Transmit Category #4. TCP - Ventana de Recepción TCP. Tamaño de la Ventana El tamaño óptimo de la ventana quedaría totalmente relacionado con la capacidad de la conexión. La capacidad de la conexión está limitada por el BW (rb) disponible y el retardo ida y vuelta observable (RTT). W. L = RTT . rb. Para que la eficiencia sea del 100% Por ejemplo, un enlace T1: 1.544 Mbps x 60 ms = 11580 bytes. Pero en un enlace T3: 45 Mbps x 60 ms = 337.500 bytes > 65.535 bytes. En el caso de T3 la capacidad del pipe es superior al tamaño de la ventana máxima. ¿Qué consecuencias habría? ¿Cómo es posible solucionar estos inconvenientes?. TCP - Ventana Deslizante TCP - Timeout C1 – GET de cliente HTTP [1010], win 251 S2 – ACK retardado, observar NS. S3 – Datos [590] S4 – Datos [222] C5 – ACK retardado reconoce 3 y 4, 590+222=812 C6 – Datos [1018] S7 – ACK retardado reconoce 6. S8 – Datos [523] S9 – Datos [223] C10 – Piggybacking [1018] S11 – ACK parcial de 10 S12 – Datos [341] S13 – Datos [43] C14 – ACK retardado. S15 – ReTx de 12 y 13 (repacketization). C16 – ACK 15. C17 – Datos [631] S18 – Datos [384] S19 – Datos [341] S20 – Datos [43] TCP - Timeout C21 – ACK 18,19 Y 20. C22 – Datos[631]. S23 – ACK 22 S24 – Datos [341] S25 – Datos [43] C26 – ACK retardado de 24 y 25 C27 – Datos [628] S28 – ACK 27 S29 – Datos [341] S30 – Datos [43] C31 – ACK retardado de 29 y 30. C32 – Datos [757] S33 – ACK 32 C34 – Datos [115]. S35 – ACK 34. S36 – Datos [516] S37 – Datos [1305] C38 – ACK 36 y 37. C39 – Datos [552] S40 – ACK 39 TCP – Rx ACK´s duplicados S1 – Datos[53]. S2 – Datos[505]. S3 – Datos[47]. Se infiere que el S ha Tx (56836 -1) bytes y Rx correctamente y en orden hasta el byte 10987. C4 – ACK 1, 2 y 3 . Observar NS = 13178 vs ACK del Server = 10988. S5 – Datos [41] , ACK 10988. C6 – Datos [41] S7 – ACK 10988 C8 – Datos [1460] C9 – Datos [24] S10 – ACK 10988 S11 – ACK 10988 C12 – ReTx Datos [1460] S13 – ACK 15423. TCP – Control de Congestión Estrategia de T.O. y ReTx ofrece un mecanismo implícito para percibir congestión. No es necesario agregar otro mecanismo explícito (segmentos especiales). T.O. pérdidas ; ACK´s duplicados Rx desordenada. Van Jacobson propuso 4 algoritmos: Slow Start, Congestion Avoidance, Fast Retransmit y Fast Recovery. Stevens dio definiciones claras en RFC 2001. La propuesta es: ante pérdida de paquetes bajar la velocidad. win es el modo que tiene el Rx de bajar la velocidad del Tx. Que el Tx detectara sólo y actuara en consecuencia sería lo ideal. Definición de cwnd (congestion window): parámetro variable según la situación de congestión durante una conexión. Siempre W =(cwnd, win)mín. Wópt = RTT x rbmín La idea es W -> Wópt. TCP - Slow Start. ¿Cómo debería iniciarse una conexión TCP? ¿Es lo mismo si se Tx sobre una LAN o una WAN? ¿Por qué no aprovechar las características de selfclocking del protocolo? Si todas las conexiones arrancaran enviando lo máximo posible al otro extremo y el Rx se encontrara del otro lado de una WAN, podría haber routers intermedios y enlaces lentos, generándose de este modo una situación de congestión en la red por saturación de las colas de paquetes. Se requiere que TCP incluya un Algoritmo de Inicio llamado Slow Start o de Arranque Lento que trabaja inyectando paquetes en la red teniendo en cuenta la velocidad con que regresan los ACK´s (en definitiva el estado de la red). Se agrega una nueva variable como ventana de operación: congestion window (cwnd), inicializada en el valor de 1 segmento. Cada vez que se recibe un ACK, cwnd se incrementa en el tamaño de 1 segmento en bytes. El Tx pude enviar (cwnd, win)mín. cwnd es Control de Flujo impuesto por el Tx /// win es Control de Flujo impuesto por el Rx. El crecimiento de cwnd es exponencial. ¿Hasta cuándo? Si en algún punto en el camino de la conexión un router comienza a descartar paquetes, el Tx percibe por situaciones de timeout y ReTx que ha sobrepasado la capacidad de la red y ha avanzado sobre un valor mayor de la cwnd. (cwnd = 1 segmento = 1024 bytes) RTT ≈ 700 ms (cwnd = 1024 bytes, win = 4096 bytes) (cwnd = 1536 bytes, win = 4096 bytes). Se Tx dos segmentos por que uno está pendiente de Rx ACK) (cwnd = 2048 bytes, win = 4096 bytes). Se Tx dos segmentos por que dos están pendiente de Rx ACK) TCP - Hasta aquí: Algoritmo Motivos Propósito Comentarios Nagle No se pueden Tx segmentos pequeños hasta que los datos en buffer de Tx no hayan Rx ACK Evita congestión por tynigramas Habilitar para Login Remoto. Deshabilitar en modo interactivo. Ventana Deslizante El Rx envía el ACK con el tamaño de ventana (win) advertida. Evitar saturación de buffers. Los Tx rápidos pueden ser detenidos con avisos de ventana win = 0 Slow Start Existe una ventana cwnd que se abre exponencialmente a medida que se reciben ACK´s, a partir de 1 segmento, luego 2, después 4, y así sucesivamente. Si un router intermedio comienza a descatar paquetes, cwnd debe decrementarse. Forma de arrancar la conexión TCP y evitar la congestión de la red. El Tx puede enviar: (cwnd, win)min. TCP - Estrategia de Timeout y ReTx TCP provee un capa de transporte confiable asociada a la existencia de ACK´s. No sólo pueden perderse segmentos de datos, si no también ACK´s. Estrategia de timeout y ReTx : cada vez que se envía un segmento, se inicia un timeout y, si este expira sin que llegue el ACK para dicho segmento, TCP lo ReTx. ¿Cuánto debe valer el intervalo de timeout? Si es muy corto, se dispararán ReTx innecesarias. Si es muy largo, se podría llegar a evaluar mal situaciones de congestión, esperando demasiado tiempo para ReTx. TCP maneja 4 timers por conexión: Timer de ReTx: Cuando se espera un ACK TCP retransmite los datos si este timer expira (no viene ACK) => Se impone una medición de RTT. RTO (ReTx TimeOut) es el temporizador de ReTx. Timer persist: Para continuar recibiendo avisos de ventana cuando se ha recibido un aviso de win = 0. Timer de keepalive: para situaciones de half open. Timer 2MSL: para el estado TIME_WAIT, para que se reciba el último ACK (el del segmento FIN) y evitar re-encarnaciones de la conexión. TCP - Estrategia de Timeout y ReTx Se verán timeouts e intentos de ReTx con crecimiento exponencial: 1, 3, 6, 12, 24, 48, 64 segundos. Este incremento en cada intento se denomina Exponential back off. Finalmente, luego de cierta cantidad de intentos, se Tx un RST sin datos. TCP - Estrategia de Timeout y ReTx La medición de RTT es fundamental para la estrategia de timeout. La medición de RTT debe asignar un valor al RTO. El RTT se debería medir como el intervalo de tiempo transcurrido entre que se Tx un byte y se Rx el ACK para el mismo, aunque no siempre se da una correspondencia unívoca (existen ACK´s acumulativos). TCP - Estrategia de Timeout y ReTx. Cálculo RTO. La especificación original: R <— α R + (1 – α) M. RTO = β R. M = RTT medido. R = Estimador. α = factor de suavizado, valor recomendado 0.9. β = factor de varianza del retardo, valor recomendado 2. Así el 90% de la estimación actual se apoya en la estimación previa y sólo el 10% en la medición actual. Jacobson notó que esta estimación producía ReTx innecesarias cuando no se pueden seguir las fluctuaciones de la red. Estas suman carga en una situación de congestión. Por ejemplo, si M aumenta mucho, R tarda en alcanzar este valor y el RTO continúa siendo bajo, disparando ReTx en un contexto donde el RTT ha aumentado. Además de la media es necesario seguir las variaciones de varianza de la medición. De esta manera se daría mejor respuesta al caso de grandes fluctuaciones. A = Estimador del promedio de RTT, D = Desviación media suavizada. Err = Diferencia entre valor medido y el estimado actual. g = 1/8, h = ¼. Cálculo con aritmética de enteros. TCP - Cálculo RTO - Algoritmo de Karn El RTO hace backoff exponencial cada vez que vence. Cuando se produce una ReTx, el RTO hace backoff exponencial y el paquete se ReTx con este valor mayor de RTO. Cuando se Rx el ACK, existe un problema de ambigüedad en la recepción del ACK: ¿Es del primer segmento o de la ReTx?. Karn: No actualizar estimadores hasta que no llegue ACK para un segmento que no ha sido ReTx. Trama 1 RTO RTO backoff Trama 1(ReTx) ACK 2 Trama 2 RTO medir ACK 3 Ambigüedad de ACK TCP - Problema de Congestión Si observáramos una Tx TCP y graficáramos el Nº de Secuencia en función del tiempo, obtendríamos una gráfica como la de la figura. La pendiente nos indicaría la velocidad de transferencia. Los picos hacia abajo, las ReTx´s. La ReTx se puede disparar por ausencia de ACK´s o por recibir ACK´s duplicados. En el caso de pérdida de un único segmento, el Rx editará un ACK duplicado por cada segmento que llegue ok. Los duplicados son indicadores de pérdida pero de continuidad de conexión. En este caso TCP actuará de un modo especial. TCP - Algoritmo Congestion Avoidance. Recordar que Slow Start es la forma de iniciar la conexión. También se debe enfrentar la pérdida de paquetes de paquetes de alguna manera, interpretándola como situación de congestión de algún punto en la red. Los indicadores de pérdida son: Timeout y Recepción de ACK´s duplicados. Cuando hay congestión, el propósito sería disminuir la velocidad de transmisión de paquetes hacia la red. Pare ello, se puede combinar el Algoritmo de Slow Start con otro denominado Congestion Avoidance. Verdaderamente se implementan juntos. Aparece un nuevo parámetro denominado Tamaño Umbral de Slow Start, ssthresh. Trabaja en conjunto con cwnd. Cada uno de estas variables se mantiene sobre una base por conexión. Al iniciarse una conexión se configuran sus valores: cwnd = 1 segmento, ssthresh = 65.535 bytes. TCP - Algoritmo Congestion Avoidance. 1. Al inicio de la conexión cwnd = 1, ssthresh = 65535 bytes. 2. TCP Tx W = (cwnd, win)min. Congestion Avoidance es Control de Flujo impuesto por el Tx. El aviso win es Control de Flujo impuesto por el Rx. El primero se basa en la estimación de congestión que el Tx puede percibir, el segundo se relaciona con el espacio de buffer disponible en Rx. 3. Cuando hay congestión (timeout ó ACKs duplicados), ssthresh = W/2 (pero al menos 3 segmentos). Si la congestión es por timeout, cwnd = 1 (o sea slow start). 4. Cuando se reconocen datos nuevos, se aumenta cwnd, pero la manera en que se aumenta depende si estamos haciendo slow start o congestion avoidance. Si cwnd ≤ ssthresh, estamos en slow start. Si cwnd > ssthresh estamos en congestion avoidance. Slow start continúa (cwnd aumenta exponencialmente por cada ACK recibido) hasta la mitad de camino donde se produjo la congestión (valor W/2 almacenado en ssthresh). Luego empieza Congestion Avoidance (crecimiento lineal de cwnd, uno por cada RTT, no importa cuantos ACK´s se reciban). TCP - Algoritmo Congestion Avoidance. En este ejemplo, en el instante previo al 0, se produjo congestión por timeout. En ese momento, W era 32 segmentos => ssthresh = 16. Arranca slow start y cwnd crece exponencialmente hasta llegar al umbral. A partir de allí el crecimiento es lineal, hasta que se produzca una nueva situación de congestión, suponiendo que no hay límite en el buffer de Rx. TCP - Algoritmo Congestion Avoidance. TCP - Algoritmos Fast ReTx y Fast Recovery Jacobson propuso una modificación del Algoritmo de Congestion Avoidance en los 90. Cuando TCP recibe un segmento fuera de orden, debe generar un ACK duplicado sin retardos. De esta forma el Tx se entera que llegó un segmento fuera de orden y cuál es el segmento que el Rx espera recibir. No se puede saber si se perdieron segmentos o simplemente se retrasaron. Si fuera el segundo caso, probablemente luego de un par de duplicados todo volvería a la normalidad y se recibiría un ACK que incluya el segmento fuera de orden. Si se recibieran 3 o más duplicados, se podría inferir que el segmento se ha perdido. TCP entonces ReTx el segmento que aparentemente se perdió. (fast retransmit). Luego de esto se aplica Congestion Avoidance (fast recovery) No se realiza slow start por que la recepción de duplicados implica que los segmentos siguen llegando, o sea que los datos están fluyendo en la red y entonces no habría por qué comenzar de nuevo. TCP - Algoritmo Jacobson 1. Cuando llega el tercer ACK duplicado, ssthresh = W/2, cwnd = W/2 + 3 (cwnd > ssthresh). ReTx el segmento perdido. 2. Cada vez que llegue un ACK duplicado, incrementar cwnd = cwnd +1. Tx si el valor de cwnd lo permite. 3. Cuando llegue ACK nuevo, cwnd = ssthresh (valor del paso 1). Este debería ser el ACK de la ReTx del paso 1, un RTT luego de la misma. Además, debería reconocer todos los segmentos intermedios enviados entre el paquete perdido y la recepción del primer ACK duplicado. Este paso es congestion avoidance, dado que estamos bajando a la mitad de donde estábamos cuando se perdió el paquete. Congestion Avoidance cae en este Algoritmo cuando se producen 3 ACK´s duplicados. Si la congestión es por timeout, simplemente se arranca con slow start. TCP - ACK´s duplicados TCP – ACK nuevo TCP – Evolución cwnd TCP. Algoritmos para Evitar Congestión. Congestion Avoidance Aumento exponencial de la ventana de inicio slow start, cwnd. Indicación de pérdida de paquetes: timeout o ACK´s duplicados. Evita la pérdida de paquetes. Es independiente de Slow Start pero trabajan juntos. Fast Retransmit Si se Rx 3 o más ACK´s duplicados, se considera una indicación fuerte de que un segmento se ha perdido. ReTx de segmento perdido sin esperar que venza el RTO. Fast Recovery Luego de la ReTx No se reduce el rápida se aplica flujo de repente Congestion yendo a Slow Avoidance. Start. Cuando hay congestión, la velocidad de Tx de paquetes debería desacelerarse. Si sólo se Rx 1 o 2 duplicados, es indicación de la llegada de segmentos fuera de orden. Si el tercer duplicado se Rx, es indicación de pérdida. TCP. Timer Persist Cuando el aviso de ventana es nulo (win = 0) se para el flujo desde el Tx. El Rx debe actualizar el aviso de ventana en un ACK cuando se desocupa el buffer. Es lo que se llama window update. ¿Qué sucede si el ACK se pierde?. Situación de deadlock. El Timer Persist tiene sentido en estos casos. Arranca al recibir el mensaje de win = 0. Expira al recibir la actualización. Se emiten queries periódicos al Rx (anunciante de win = 0). Se denominan window probes. El período entre probes aumenta exponencialmente: cada 6 / 12 / 24 / 48 / 60 seg. Luego se establece en 60 seg hasta la actualización o el fin de la conexión. Si el último aviso de ventana fue ACK 400, win 0. El window probe será 400:401(1) ACK xx win xx. O sea que es un número que sobrepasa el final de la ventana, lo cual está permitido. TCP está obligado a contestar un mensaje que sobrepasa la ventana y lo hace enviando ACK 400 win actualizada (el reconocimiento es al último byte Rx ok, que no es el 400). Problema: Se puede producir el Síndrome de la Ventana Tonta. TCP. Síndrome de la Ventana Tonta TCP. Síndrome de la Ventana Tonta El Síndrome de la Ventana Tonta puede ocurrir cuando el Rx anuncia tamaños de ventana pequeños (en vez de esperar hasta poder anunciar un tamaño mayor) y el Tx empieza a enviar datos llenando la ventana nuevamente, disparando nuevos anuncios de win = 0. Para evitarlo existen reglas: 1. El Rx no debe avisar hasta no tener lugar para 1 segmento completo o la mitad del buffer de Rx (el más pequeño). 2. El Tx no envía datos a menos que (a) pueda enviar 1 segmento. (b) pueda enviar la mitad del tamaño del buffer de Rx, o (c) pueda enviar lo que tiene y, o no está esperando ACK (o sea no tiene datos pendientes) o el Algoritmo de Nagle está deshabilitado. TCP. Timer Keep Alive Cuando en una conexión ya establecida no hay datos para intercambiar, podría permanecer indefinidamente en ese estado, aunque cayeran routers o enlaces en el medio, a menos que algunos de los extremos rebootee. Las Aplicaciones generalmente carecen de timers inactividad y existe en este sentido una discusión. Sería apropiado que un S se enterara si un C inactivo ha caído y permanece en ese estado o ya ha rebooteado, para no distraer recursos en el mismo. La detección sería engañosa si en realidad lo que ha sucedido es una falla transitoria en algún punto de la red. Si en una conexión no hay actividad durante 2 hs, el extremo S Tx una probe al C. El C podría estar en 1 de 4 posibles estados. para detectar TCP. Timer Keep Alive 1.C todavía activo y alcanzable: C responde el probe TCP y el S resetea el timer a otras 2 hs. Cada vez que haya tráfico en la conexión el timer se resetea a 2 hs. Todo se hace a nivel TCP. 2.C caído y en proceso de rebooteo: C no responde. S hace timeout a los 75 seg y repite la generación de probes cada 75 seg durante 10 veces. Si no Rx respuesta, considera la conexión caída y la termina. TCP genera un error a la aplicación. 3.C caído y ya rebooteado: C responde con un RST y Se termina la conexión. TCP genera un error a la aplicación. 4.C activo pero no alcanzable: Se ve como la situación 2. TCP genera un error a la aplicación. El Nº de Secuencia de la Probe es uno menos que el que el otro extremo espera Rx (por ejemplo si el último ACK fue ACK 18, el Nº de Secuencia será 17), o sea no es válido y no lleva datos, de esta forma se dispara un ACK 18 (duplicado). TCP. Nuevas opciones A medida que la tecnología avanza, la velocidad de las comunicaciones comienza a crecer y, a velocidades superiores a T3 o Gbit, se empiezan a ver limitaciones en TCP. En este sentido se proponen modificaciones para tender a la máxima eficiencia del protocolo. En nuevas redes, el producto BW x RTT es mayor. Se habla de Long Fat Pipes. Los tamaños de ventana deberían superar los 65.535 bytes => nueva opción: Window Scale. C = BW x RTT. Ethernet: 100 Mbps x 1 ms = 12.500 bytes. T1: 1.544 Mbps x 30 ms = 5790 bytes. T1 satélite: 1.544 Mbps x 500 ms = 96.500 bytes. T3 transcontinental: 45 Mbps x 60 ms = 337.500 bytes. LFN`s (elefan`s) son enlaces de alta capacidad. TCP sobre LFN`s es lo que se conoce como Long Fat Pipes. Empiezan a aparecer problemas con el tamaño de la ventana, win < 65.536 bytes, que se solucionan con opción winscale. TCP. Nuevas opciones. Por las altas velocidades, puede suceder que el Nº de Secuencia de toda la vuelta y se empiece a repetir numeración sobre la misma conexión => PAWS (Protection Against Wrapped Sequences). También nueva opción: Timestamp. Para medición confiable de RTT => nueva opción: Timestamp. RTTM (RTT Measurement o Mechanism) Para bajar el número de segmentos intercambiados entre dos extremos, evitando el 3-way handshake y los 4 segmentos finales, se empieza a hablar de Transacciones T/TCP. La pérdida de paquetes en estas redes puede resultar en una disminución importante de la eficiencia. Típicamente la pérdida de un segmento atendida por Fast ReTx y Fast Recovery evita que el pipe drene. En el caso de pérdida de más de un segmento, se atiende por Slow Start, drenando el pipe y se demora muchos RTT para llenarlo nuevamente. Ayudar con SACK (Selective ACK) puede ser una solución para generalizar Fast ReTx y Fast Recovery al manejo de múltiples paquetes perdidos por ventana. Todas las propuestas buscan ser compatibles hacia atrás para interoperabilidad. TCP. Long Fat Pipes . Nº de Secuencia En el caso de LFN`s la confiabilidad TCP puede verse afectada por violación de suposiciones tradicionales de detección de duplicados y números de secuencia. Con 32 bits se pueden numerar 4.294.967.296 bytes (4GB). Si la velocidad de transferencia es lo suficientemente alta, la numeración puede dar la vuelta (volver a empezar) dentro del tiempo en que un segmento se retrasa por encolamiento. Existe una probabilidad cierta de re-uso accidental del Número de Secuencia. Por ejemplo un ¨segmento viejo duplicado¨ (duplicado retrasado) se entrega al Rx en un momento en que su Nº de Secuencia corresponde a alguno de los pendientes en la ventana. No existe en este caso mecanismo que evite el error. Si el segmento duplicado retrasado fuera un ACK se podría trabar la conexión forzando un posible RST sobre la misma. En TCP, la probabilidad de que un segmento retrasado de una conexión anterior (encarnaciones) ya terminada, que aparezca sobre una encarnación de la misma, se maneja con TTL y 2MSL. TCP. Long Fat Pipes . Nº de Secuencia Se debe verificar 232 x 8 / rb > 2 MSL => 231 / B > MSL. B es la velocidad en bytes/seg. y Twrap = 231/B. Si calculamos Twrap para diferentes redes: DS1 (1.5 Mbps) Twrap = 3.6 días Ethernet (10 Mbps) Twrap = 30´ DS3 (45 Mbps) Twrap = 380¨ Fast Ethernet (100 Mbps) Twrap = 170¨ Gbit (1 Gbps) Twrap = 17¨ A partir de DS3, el Twrap comienza a ser comparable a los 2´ establecidos para MSL en la especificación de TCP. El campo de ventana de 16 bits limita la velocidad de transferencia efectiva a Beff =216/RTT (bytes por segundo). Si el RTT es lo suficientemente largo, Beff se limitaría bastante, permaneciendo por debajo de MSL el tiempo de wrap. Por ejemplo, en un backbone transcontinental un RTT de 60 mseg es típico, Beff quedaría limitada efectivamente a Beff =216/RTT = 1.092 Mbytes/seg. y todavía Twrap = 231/Beff =1966 seg verificaría la restricción. En cambio, en una LAN FDDI (100 Mbps) de 10 km de diámetro implica un RTT = (2 x 104)/(3x 108) = 67µseg. C = rb x RTT=100 Mbps x 67µseg = 837 bytes. Una conexión sobre esta LAN con una ventana de sólo 837 bytes, tiene Twrap comparable a MSL. TCP. Long Fat Pipes . Nº de Secuencia Una posible solución al tema del recomienzo de la Numeración de Secuencia dentro de una misma conexión sería aumentar la cantidad de bits del campo. Para no tener que realizar cambios en el header TCP, se ideó un mecanismo, llamado PAWS, que extiende la confiabilidad de TCP en el caso de redes de alta velocidad. También PAWS usa la opción Timestamp, para proteger la conexión ante la aparición de segmentos viejos duplicados. No precisa sincronismo entre Tx y Rx. Sólo es necesario que el valor de timestamp sea monótonamente creciente. Se toma el valor como un extensión de 32 bits del número de secuencia. Si se recibe un paquete con timestamp más viejo, será descartado. Peligro de ataque: Si se envía al server un paquete con un número de secuencia válido y un timestamp bastante posterior, se invalidarán todos los paquetes realmente recibidos del transmisor original. TCP. PAWS . Nº de Secuencia T< MSL La opción de timestamp también permite soporte para situaciones de Nº de Secuencia repetidos sobre una misma conexión. La idea es que un segmento puede ser tomado como un duplicado viejo y descartado si el valor de timestamp es menor que el recientemente recibido sobre la conexión. La mayor opción ventana posible es 230. Veamos el caso de Tx 6 GB de la siguiente manera: Time BytesTx NºSeq Timestamp Tx Rx A 0G:1G 0G:1G 1 OK B 1G:2G 1G:2G 2 OK pero se pierde ACK y B es ReTx C 2G:3G 2G:3G 3 OK 3G:4G 3G:4G 4 OK 0G:1G 5 OK 1G:2G 6 (Como 2 < 5 ó 6, entonces PAWS lo descarta) OK pero un segmento duplicado reaparece. sino no reaparece D E F 4G:5G 5G:6G NºSeq da la vuelta TCP. Opción de Escalamiento de Ventana Tipo: 3 (1) // Longitud: 3(1) // Shift.cnt.(1) Expande la ventana original de 16 bits a un valor que TCP mantiene internamente en 32 bits y usa un factor de escala para trasladar el valor en el campo original de 16 bits. Shiftcount puede tomar valores entre 0 (sin escalar) y 14 (65.535 x 214 = 1GB)) Se especifica un valor de shift count de un byte en el campo de opciones. La verdadera win recibida se corre a la izquierda según el valor de shift count. El máximo es14. TCP determina si un segmento de datos es “viejo" o "nuevo" testeando si su Número de Secuencia está dentro de los 231 bytes desde el borde izquierdo de la window: sino lo está, lo descarta por “viejo". Para asegurarse que datos nuevos no se consideren erróneamente como viejos y al revés, el borde izquierdo de la ventana del Tx debe estar al menos 231 alejado del borde derecho de la ventana del Rx. Similarmente sucede con el borde derecho de la ventan del Tx y el borde izquierdo de la ventana del Rx. Dado que los bordes derecho e izquierdo de cualquiera de ambas ventanas, del Tx y del Rx, difieren por el tamaño de la ventana y, dado que las ventanas del Tx y del Rx pueden estar fuera de fase por como máximo el tamaño de la ventana, la restricción mencionada implica que el 2 x el tamaño máximo de la ventana debe ser menor que 231. La opción sólo puede aparecer en SYN y queda fijo en cada dirección al establecimiento. Se comunica el factor de escala que se aplicará a la ventana de Rx propia. El factor es una potencia de 2 y se codifica logarítmicamente para poder ser aplicado mediante shift binario. El extremo en open activo lo Tx y el otro puede hacerlo sólo si Rx la opción. Si el Rx no transmite la opción, el primero debe configurarla en 0 (interoperabilidad). Puede ser distinto en cada dirección. Todas las ventanas se tratan como valores de 32 bits: SND.WND, RCV.WND, cwnd, etc. TCP. Opción de Escalamiento de Ventana Se definen Snd.Wind.Scale que se aplica a campos win entrantes y Rcv.Wind.Scale que se aplica campos win salientes. La opción se envía con Shift.cnt = R que sería el valor que TCP usaría para su ventana de Rx. Al recibir un segmento SYN con Shift.cnt = S, TCP configura la variable Snd.Wind.Scale a S y Rcv.Wind.Scale a R. Sino, las configura en 0. El campo win (SEG.WND )en cada segmento posterior entrante escala la ventana: SND.WND= SEG.WND << Snd.Wind.Scale El campo win (SEG.WND )en cada segmento posterior saliente escala la ventana: SEG.WND = RCV.WND >> Rcv.Wind.Scale. TCP. Escalamiento de Ventana Factor de escalamiento R SYN 3/3/R SYN ACK 3/3/S Factor de escalamiento S SEG.WND = RCV.WND >> S SND.WND = es el valor escalado SEG.WND SND.WND = SEG.WND << S Multiplica SEG.WND = RCV.WND >> R SEG.WND Divide SYN 3/3/R => Tipo 3, Long 3, shift.cnt R Divide SEG.WND = es el valor en win SND.WND = SEG.WND << R Multiplica TCP. Medición de RTT Tipo: 8 (1) // Longitud: 10(1) // TS Value (TSVal)(4) // TS Echo Reply (Tsecr) (4) Calcular RTT por cada ventana transmitida puede ser correcto si la ventana fuera de 8 segmentos, puesto que se estaría muestreando el valor a una velocidad razonable (1/8 la de los datos). Sin embargo, si la ventana es de 100 segmentos, la medición puede tornarse insegura o disparar ReTx innecesarias y entonces sería imposible medir RTT de manera segura. Con esta opción se puede Tx en cada segmento un sello de tiempo que el Rx lo copia en el ACK de regreso. Entonces el Tx realizando una simple diferencia puede medir RTT de manera segura para cada ACK. Este mecanismo se denomina RTTM. El Nº de 32 bits del Timestamp es monótonamente creciente y como el Rx hace eco, no interesan ni unidades ni sincronismo entre hosts. La RFC 1323 determina que el número debería crecer en 1 por cada ms. El extremo que hace open activo especifica la opción en el SYN, el otro sólo puede especificarla si la Rx. Recordar que un ACK puede reconocer varios segmentos. Si el Rx transmite ACK por varios segmentos ¿Cuál Timestamp recibido copia de regreso?. Para no mantener tanta información en cada extremo, sólo se almacena un timestamp por conexión y un sencillo algoritmo elige cuando debe actualizarse. TCP. Medición de RTT Si se recibe más de una opción Timestamp antes de enviar un segmento de respuesta, TCP debe elegir sólo un valor de los TSvals para hacer eco e ignorar los otros. Para minimizar el número de Tsvals no procesados almacenados, habría que requerir al Rx que retenga como máximo 1 Timestamp en el bloque de control de la conexión. Hay 3 situaciones a considerar: ACKs retardados. El TCP del Tx de datos debe medir el RTT efectivo, incluyendo el tiempo adicional debido al retardo del ACK, sino retransmitiría innecesariamente. O sea que, cuando aparecen ACK´s retardados, el Rx debería responder con el valor de Tsval del segmento no reconocido que haya llegado antes. Cuando existen ¨agujeros¨ en los Nºs de Secuencia por segmentos perdidos. El Tx. Continuará enviando hasta llenar la ventana y el Rx puede generar ACKs a medida que lleguen los segmentos fuera de orden para ayudar a disparar "fast retransmit". Un segmento perdido es signo de congestión y en ese caso el Tx debe ser conservador en cuanto a la ReTx. Aún más, es mejor que sobre estime el RTT, en vez de subestimarlo. Por este motivo, el ACK de un segmento fuera de orden debería contener el Timestamp del segmento más reciente que haya avanzado la ventana. Un ¨agujero¨ llenado en los Nºs de Secuencia. El segmento que lo llena representa estado más reciente de la red. Por otro lado, el RTT medido de un segmento reciente probablemente incluiría un valor sesgado. Por eso, el Timestamp del último segmento (el que llena el agujero) es el que debe ser enviado en el eco. TCP. Opción de Sello de tiempo A, TSval=1, Tsecr=120 ACK(A), TSval=127, Tsecr=1 B, TSval=5, Tsecr=127 ACK(B), TSval=131, Tsecr=5 Pausa C, TSval=65, Tsecr=131 ACK(C), TSval=191, Tsecr=65 • REGLA sobre cuando medir: • Un valor Tsecr recibido se puede usar sólo para actualizar la medición de RTT si reconoce nuevos datos (avanza el borde izquierdo de la ventana Tx). • En este caso el extremo B no está Tx datos, por lo tanto no mide el RTT. La pausa infla el RTT que se podría medir TCP. Opción de Sello de tiempo A, TSval=1 • REGLA para ACKs retardados: B, TSval=2 En el caso de Ack´s retardados Se hace eco del segmento más viejo no reconocido. Esto es por que el Tx debe medir un RTT efectivo que incluya el tiempo adicional debido al ACK retardado, sino se producirán ReTx innecesarias. C, TSval=3 ACK(C), Tsecr=1 • En este caso existe una secuencia de paquetes y alguno de los ACK´s se retarda. Se hace eco del segmento más viejo no reconocido. TCP. Opción de Sello de tiempo A, TSval=1 ACK(A), Tsecr=1 C, TSval=3 ACK(A), Tsecr=1 B, TSval=2 ACK(C), Tsecr=2 E, TSval=5 ACK(C), Tsecr=2 • REGLA para segmentos perdidos y segmentos que llenan el hueco: • En el caso de segmentos perdidos. La pérdida es probablemente indicación de congestión y el Tx debería ser conservador respecto de la ReTx. Por este motivo el ACK de un segmento fuera de orden contiene el eco del segmento más reciente que haya avanzado la ventana. Cuando llega el faltante, el eco es el de este segmento. TCP. Opción ACK Selectivo En el caso de pérdida de múltiples segmentos, el esquema tradicional de ACK puede hacer que TCP ReTx innecesariamente o deba esperar RTT para saber sobre cada paquete perdido. En general se empieza a perder eficiencia por pérdida de selfclocking. Selective Acknowledgment (SACK) corrige esta situación y permite que el Rx informe al Tx cuáles segmentos han llegado bien de tal manera de ReTx sólo los segmentos perdidos. En realidad se trata de dos opciones: SACK-permitted, que se puede enviar en el SYN y la otra es la opción SACK que se intercambia durante la fase de establecimiento. Sack-Permitted:Tipo: 4(1) // Longitud: 2(1). SACK: informa sobre bloques no contiguos de datos que ya han sido recibidos y se está esperando llenar los huecos en el espacio entre bloques. Cuando se Rx los segmentos perdidos, se los reconoce de la manera habitual. La opción no cambia el significado del campo de ACK. TCP. Opción ACK Selectivo Left Edge of Block: Primer Nº de Secuencia del Bloque. Right Edge of Block: Nº de Secuencia del siguiente Byte esperado luego del bloque. O sea los bytes por debajo de (Left Edge of Block - 1) y por encima de (Right Edge of Block), no han sido recibidos. Una opción SACK que especifica n bloques tendrá una longitud de (8n+2) bytes, es decir que se puede especificar un máximo de 4 bloques (36 bytes). Se espera que SACK se usa en conjunto con Timestamp (10 bytes, más 2 de relleno) . En estos casos sólo se permiten 3 bloques. Las opciones SACK se deberían incluir en todos los ACK´s que no reconozcan el Nº de Seq. mayor de la cola de datos recibidos. Se trata de los casos de llegada de datos fuera de orden. Los ACK´s duplicados LE RE deberían llevar esta opción. TCP. Opción ACK Selectivo Caso 1: El borde izquierdo de la ventana es 5000, el Tx envió 8 segmentos (c/u de 500bytes). Se Rx los 4 primeros y se pierden los otros 4. TCP. Opción ACK Selectivo Caso 2: Se pierde el primer segmento. Los siguientes 7 se reciben bien. TCP. Opción ACK Selectivo Caso 3: Se pierden el segundo, el cuarto, el sexto y el octavo. TCP. Opción ACK Selectivo Cont. Caso 3: Luego se Rx el 4º segmento y, posteriormente el 2º. Bibliografía TCP/IP Illustrated, Volumen 1 The protocols W. Richard Stevens Chapter 19, Chapter 20, Chapter 21, Chapter 22, Chapter 23, Chapter 24