TCP

CARACTERSTICAS

Orientado a conexin.
Confiable.
Ordenado.
Byte Stream (todas las operaciones las realiza a nivel de byte).
Ventana.
Control de flujo y congestin.

ESTRUCTURA
Encabezado

LA PSEUDOCABECERA TCP
La forma de computar la suma de verificacin de TCP es algo
extraa. Se intenta que el TCP Checksum sirva no slo para detectar
errores, sino para comprobar que el datagrama ha llegado al destino
donde fue enviado.
Para comprobarlo no basta con mirar los nmeros de puerto de la
cabecera TCP, pues stos no diferencian mquinas unas de otras. Es
necesario incluir las direcciones IP dentro de la suma de verificacin, aun
cuando stas no forman parte del segmento TCP.

Para resolver esta aparente contradiccin, la mquina origen monta

una pseudo-cabecera que incluye:

Direcciones IP de origen y destino

Un octeto 0 de relleno, para alinear en palabras de 32 bits.
El cdigo de 8 bits del protocolo segn el estndar IP (17 para UDP
y 6 para TCP ).
Un campo de 16 bits para la longitud del datagrama (sin incluir el
pseudo-encabezado).
Esta informacin debe coincidir con la de la cabecera IP.

Una vez montada la pseudo-cabecera, se pone a cero el campo

checksum de la cabecera TCP, se computa la suma del pseudo-cabecera,
la cabecera y el paquete de datos en complemento de 16 bits y se
almacena en dicho campo. La pseudo-cabecera no se transmite
realmente, y es desechada.

Cuando el segmento llega a su destino, la mquina receptora debe

volver al construir el pseudo-encabezado usando la informacin de la
cabecera IP y comprobar la suma de verificacin.

Obsrvese que este truco es una clara violacin de la arquitectura

en capas, que se ha hecho por motivos puramente prcticos. Esto hace
que UDP dependa claramente de IP y ms concretamente del formato de
su cabecera, lo cual es muy criticable.

MULTIPLEXACIN
La multiplexin es la combinacin de dos o ms canales de
informacin en un solo medio de transmisin usando un dispositivo
llamado multiplexor. El proceso inverso se conoce como demultiplexin.

TCP ESTABLECIMIENTO DE LA CONEXIN

Se intercambian 3 segmentos.
Se enva el MSS (Mxima longitud del segmento)

MXIMA LONGITUD DEL SEGMENTO (MSS)

Los segmentos enviados a travs de una conexin no son todos
del mismo tamao. Sin embargo, los dos extremos pueden acordar un
tamao mximo para los segmentos que sern transferidos en la
conexin. En TCP se utiliza el campo "opciones" para conseguir
negociar ciertos parmetros con la capa de transporte del otro extremo.
Una de ellas permite que el protocolo especifique un tamao mximo
de segmento (MSS), ste ser el nmero mximo de bytes que est
dispuesto a recibir en un mismo segmento. Es importante por ejemplo
cuando se conectan computadores con distintas capacidades de
memoria ya que alguna de ellos puede ser ms restrictiva.
En computadores conectados a una misma red fsica, TCP
computar un MSS de tal forma que los datagramas IP se correspondan
con la MTU de la red. Si los computadores no estn en la misma red
fsica, se puede intentar descubrir cual es la MTU mnima en el camino
que hay entre los dos extremos.
La eleccin de un tamao mximo de segmento apropiado puede
llegar a ser bastante difcil ya que si se escoge demasiado grande o
demasiado pequeo no se conseguir una utilizacin apropiada de la
red. Si es muy pequeo la gran proporcin entre las cabeceras y los
datos har que se produzca un uso ineficiente del ancho de banda. Por
otro lado, si es demasiado grande y viajan a travs de una red con MTU
pequea, IP deber fragmentarlos y a diferencia de un segmento TCP, un

fragmento no se puede confirmar o retransmitir de forma independiente

por lo que todos los fragmentos debern llegar correctamente o se
tendr que retransmitir todo el datagrama de nuevo.
Tericamente el tamao ptimo de segmento ocurre cuando los
datagramas IP llevan segmentos lo ms grande posibles sin que haya
necesidad de fragmentarlos.

Caractersticas

Default = 536 bytes.

Diferente para cada sentido de la conexin.
Vinculado al MTU ( MSS=MTU Cabecera IP Cabecera TCP).

Nmero de Secuencia

Nmero de 32 bits.
Valor inicial fijado en el establecimiento de la conexin, (ISN).
TCP desagrega el stream de bytes en segmentos.
Cada segmento tiene asociado el nmero de secuencia.
Indica su ubicacin en el stream de bytes.

VENTANA DESLIZANTE
SNDROME SILLY WINDOW
ALGORITMO DE NAGLE
TIMEOUT Y RTT
ESTIMANDO EL RTT
FIJANDO EL TIMEOUT
AMBIGEDADES
ESTIMADOR DE KARN
CONGESTIN

Controlar vs. evitar

Modelo end-to-end
o Los extremos son la fuente de la demanda.
o Los extremos deben estimar los tiempos y grado de
congestin y reducir la demanda.
o Los nodos intermedios deben monitorear el estado de la red.
Modelo basado en la red
o Los extremos no son confiables.
o El nodo de la red tiene control sobre el trfico.
o Acciones ms rpidas.

TCP CONGESTIN

Utiliza tres variables:

o cwnd: ventana de congestin.
o rcv_win: ventana del receptor publicada en el segmento.
o ssthresh: valor del umbral. Actualiza cwnd.
Para el envo
o win = min(rcv_win,cwnd)
o Inicializa el sistema y descubre la congestin rpidamente.
o Incrementa cwnd hasta la congestin -> estima el ptimo
cwnd.
o Detecta congestin por prdida de segmentos.
Desventajas
o Deteccin tarda
o Enlaces de alta velocidad -> ventanas mayores -> mayor
prdida.
o Interaccin con el algoritmo de retransmisin y tiemouts.

TCP SLOW START (INICIO LENTO)

En el comienzo o despus de congestin:

o cwnd = 1
o Despus de cada ACK:
cwnd <- cwnd+1
Pese al incremento unitario el crecimiento es exponencial.

EVITANDO LA CONGESTIN

Mantener la operacin a la izquierda del knee.

Incremento aditivo, comenzar con ssthresh, incrementar cwnd

lentamente.
Disminucin multiplicativa: cortar la ventana de congestin
drsticamente si se detecta una prdida.
Disminuir la velocidad del Slow Start.
Si cwnd -> ssthresh entonces
o Por cada ACK,
cwnd <- cwnd+1/cwnd
Cwnd se incrementa en 1 si todos los segmentos recibieron su
ACK.

DETECCIN DE PAQUETES PERDIDOS

Esperar RTO (Retransmission timeout).
RTO es usualmente dos veces RTT.
Degradacin de performance.
No esperar RTO.
Utilizar mecanismos alternativos.
Utilizar RTO si fallan los anteriores.

FAST RETRANSMIT Y FAST RECOVERY

Frente a un segmento fuera de orden se debe enviar un ACK.

Provoca duplicacin de ACKs.
Esta duplicacin se ve como debida a:
o Paquetes perdidos
o Reordenamiento de paquetes.
No se puede discriminar.
Si se reciben 3 ACKs duplicados se considera que se debe a un
paquete perdido.
Al recibir el tercer ACK repetido se retransmite sin esperar el RTO.
Eso es Fast Retransmit
Luego se ejecuta congestion avoidance, no slow start.
Eso es Fast Recovery.

INTEGRANDO....

Slow Start.
Congestion Avoidance.
Si aparecen ACKs duplicados
o Fast Retransmit y Fast Recovery.
o Congestion Avoidance.
Si RTO
o Slow Start.
Resumiendo, TCP Reno.

TCP Persist Timer

Es necesario hacer una suerte de polling.

Pueden producirse deadlocks.
Al recibirse una ventana de 0 se activa el persist timer.
Normalmente 5 segundos.
Cuando expira se enva un segmento de 1 byte para verificar el
estado del receptor.
El receptor le contesta acorde con el estado en que se encuentra.
Si el receptor vuelve a constestar con ACK , wind=0.
o Entonces el persist timer hace un back-off binario.( 10, 20,
40seg...).
o Al contestar el ACK no validando el byte recibido el emisor
contina enviando este byte de prueba.
La diferencia con el RTO es que en este caso el emisor enva
permanentemente esta prueba hasta que la ventana se
incremente o se haga un reset de la conexin.

TCP Keepalive Timer

En TCP si no hay intercambio de datos no hay trfico alguno, pero

la conexin persiste.
Persiste hasta que haya una cada en algn extremo o reboot de
alguno de los hosts.
Este timer se define para interrogar al otro extremo por su estado.
No es parte de la especificacin de TCP.
No se recomienda porque puede provocar cadas en caso que la
falla sea transitoria.
Tambin incrementa el uso del ancho de banda disponible como
cualquier otra accin de control.
Sin embargo en algunos casos es necesario
o Ej, Telnet.
o Los servidores necesitan conocer el estado de los clientes
dado que estn reservando sus recursos para atenderlos.
En el extremo en que est habilitado este timer si no hay actividad
en 2 horas enva un segmento de prueba.
El segmento de prueba es similar al de persist timer.
Puede tambin enviarse vaco como un ACK solamente pero con
un nmero de secuencia inesperado.
El receptor se puede encontrar en alguno de estos estados:
1. Activo: Responder al segmento de prueba. El emisor resetea el
timer por otras 2 horas. Si en ese intervalo aparece trfico
entonces se vuelve a resetear.
2. Cado o en proceso de reboot: El emisor no recibir respuesta y
se genera un timeout a los 75 segundos. Repite este proceso 10
veces en intervalos de 75 seg. Si no recibe respuesta finaliza la
conexin.
Estados...
3. Finaliz el reboot: el emisor recibir una respuesta que ser
un reset de la conexin.
4. Receptor activo pero inalcanzable por el emisor: el emisor no
recibe respuesta y genera un timeout de 75 seg al cabo de los
cuales retransmite el byte de prueba. Es similar al caso 2.

Performance

Depende de:
o bandwidth X delay.
Los problemas aparecen cuando ese producto es grande.
Los valores actuales estn en:
o 10^6 bits.

Problemas de performance

Lmite en el tamao de la ventana

o 2^16 bytes = 65535 bytes.
Prdida de paquetes.
o Fast retransmit y Fast recovery no son suficientes.
Medicin del Round Trip.
o Al ser medido por los extremos genera acciones tardas.
En las sesiones de alta velocidad pueden aparecer nmeros de
secuencias duplicados.
o Por wrap-around en la sesin corriente.
o Reencarnacin de la sesin.

TCP Wrap-around

El nmero de secuencia tiene 32 bits.

En velocidades altas el espacio de 32 bits puede reciclar dentro del
intervalo de tiempo que un segmento es retardado en la red.
Para evitar el reciclado se requiere una eleccin adecuada del MSL.
Para conseguir una operacin libre de este error:
o 2^31/B > MSL(seg), donde B es la velocidad efectiva del
enlace en bytes/seg.
o Twrap = 2^31/B.
Salidas posibles:
o Aumentar el nmero de bits para identificar la secuencia.
o Mecanismo PAWS (Protect Against Wrapped Sequence
numbers).

Round-trip delay time(RTTM)

Estimacin ineficiente: una muestra por ventana.

Enviar un timestamp por cada segmento transmitido.
El receptor lo responde en cada ACK.
Por diferencia se obtiene el RTT.
Se utiliza este mecanismo en ventanas grandes.
Opcin timestamp
El Echo replay es vlido si el flag de ACK est activo. Si no debe
ser 0
Se utiliza el Echo replay recibido si el segmento da acknowledge a
datos nuevos.
Si se recibe ms de un timestamp antes de enviar el echo, TCP
debe elegir uno slo de los TS a quien responder

PAWS

Definido para rechazar segmentos duplicados y reencarnaciones.

Utiliza la opcin de timestamp.
Asume que los segmentos de datos y ACK recibidos contienen un
valor de TS montono no-decreciente.
Un segmento puede ser descartado como duplicado si se recibe
con un valor de TS menor que uno anterior.
Menor que significa que si s y tson valores de TS, entonces
o s < t si
0<(t-s)<2^31
Los valores de TS enviados en <SYN> y/o <SYN,ACK> inicializan
PAWS.
No requiere sincronizacin de relojes entre emisor y receptor.

Redes LFN

Las redes LFN (Long, Fat pipe Networks/Elephant Networks) son las
que tienen un elevado ancho de banda y un elevado RTT (retardo).
El producto de ambos da una idea comparativa de dichas redes.
o Enlace va satlite de 2 Mb/s y retardo 500 ms: BW*RTT = 1
Mb
o Enlace por fibra de larga distancia de 1 Gb/s y RTT = 40 ms:
BW*RTT = 40 Mb

TCP en redes LFN

o La ventana de TCP es un campo de 16 bits. Su valor mximo es
65535 bytes.
o En TCP no es posible enviar ms de 65535 bytes seguidos sin
haber recibido un ACK
o En una red LFN con BW*RTT > 64 Kbytes el rendimiento se puede
ver limitado por este motivo. La limitacin es tanto mayor cuanto
mayor es el BW*RTT de la red

Performance de TCP en LFN