17TCP 2215KB May 16 2016 05:09:22 PM

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