Ar Tema4

1908 Arquitectura de Redes
Tema 4. Aspectos Avanzados del Protocolo TCP
Pedro M. Ruiz <pedrom@um.es>
Francisco J. Ros <fjros@um.es>
3 Grado en Ingeniera Informtica 2011/2012
Organizacin del tema

Introduccin al nivel de transporte Transporte orientado a la conexin: TCP Control de flujo en TCP Control de congestin en TCP Retransmisiones mejoradas en TCP Variantes TCP
Arquitectura de Redes - Universidad de Murcia

Contextualizacin
www.um.es Apl.1
Nivel de Transporte
sun.rediris.es
Nivel de Aplicacin
Apl.2
O.S.
D H
Data
Header
Data
Header
O.S.
D H
Nivel de Red
Nivel de Enlace
Source: CS244, Steve McKeown, Stanford University
Introduccin al Nivel de Transporte

Suministra transporte de los datos extremo a extremo (host a host). Usando los servicios del nivel de red realiza la comunicacin de forma transparente al medio fsico. Multiplexa trfico de diversas instancias (procesos) del nivel de aplicacin. La unidad de transferencia de informacin a nivel de transporte se denomina TPDU (Transport Protocol Data Unit) o simplemente segmento en TCP/IP. Generalmente las aplicaciones requieren un servicio fiable, sin prdidas ni datos duplicados. Para ello se utiliza un servicio CONS. Ej: TCP (TCP/IP), TP4 (OSI). A veces basta un servicio de datagramas CLNS (no fiable). Ej: UDP (TCP/IP), TP0 (OSI).
Arquitectura de Redes - Universidad de Murcia 5
Elementos Principales del Nivel de Transporte

Direccionamiento y multiplexacin
Identificar a los procesos orgen y destino Hacer llegar los datos de diversas fuentes al proceso destino correspondiente
Establecimiento y cierre de conexiones

Slo en nivel de transporte orientado a conexin
Control de flujo y buffers

Ajuste de las tasas de envo de datos
Control de errores
Recuperacin ante la prdida de datos en la subred
Control de Flujo, Congestin y Errores

Motivacin
Un transmisor rpido podra saturar a un receptor lento
Adaptacin de las tasas a los equipos finales
La carga ofrecida a la red puede ser superior a la mxima soportada

Buffers de routers intermedios podran llenarse Normalmente conocido como control de congestin
Algunas sesiones podran recibir muchos ms recursos que otras

Mantener equidad entre sesiones
Una subred puede perder o retrasar mensajes
Comparacin de Protocolos de Transporte en Internet

Funcin Transporte Multiplexacin Deteccin de errores Correccin de errores Control de flujo Control de congestin Establecimiento/ terminacin de conexin TCP S S S S S S S UDP S S Opcional No No No No

22
Protocolo TCP
Transmission Control Protocol (TCP), RFC 793
Implementa un transporte confiable orientado a la conexin (CONS) sobre un servicio de red no confiable (IP)
Funciones:
Establecer y terminar conexiones Intercambiar datos con las aplicaciones: multiplexar nivel de aplicacin (puertos) Gestionar los buffers, ejercer control de flujo Controlar errores, retransmitir segmentos (TPDUs) perdidos, eliminar duplicados Efectuar control de congestin
Caractersticas de TCP
Ofrece un servicio de transporte de datos entre aplicaciones dplex, fiable y orientado a conexin (establecimiento, transferencia de datos y liberacin). El octeto es la unidad de datos del interfaz. No es posible preservar unidades de mayor longitud. Los datos de usuario se dividen para ser transmitidos como datagramas IP. Se emplea el mecanismo de ventana deslizante para ejercer control de flujo y recuperarse frente a errores (generados o no recuperados por la red). La numeracin es a nivel de octeto. El tamao de la ventana puede variar a lo largo de una misma conexin.
Diagrama de Multiplexacin
Nivel de aplicacin FTP Port 21 Telnet Port 23 SMTP Port 25
Nivel de transporte (TCP)

Cab. TCP Port 23 DATOS APLICACIN
Nivel de red (IP)

Cab. IP Prot. 6 SEGMENTO TCP
Nivel de enlace (Ethernet)

Cab. MAC Etype 0800 DATAGRAMA IP CRC
25
Cabecera TCP
32 bits
Puerto de origen Puerto de destino Nmero de secuencia N(S)
20 bytes
Nmero de acuse de recibo N(R) Lon. Cab Reserv. Checksum Opciones Flags Tamao ventana Puntero datos urgentes Relleno
Flags:
URG: ACK: PSH: RST: SYN: FIN:
el segmento contiene datos urgentes el campo nmero de acuse de recibo tiene sentido el segmento contiene datos Pushed ha habido algn error y la conexin debe cerrarse indica el inicio de una conexin indica el final de una conexin
26
Campos
Origen y Destino: puertos origen y destino de la comunicacin (FTP, TELNET, SMTP, etc.) N(S): posicin del segmento dentro de la ristra de octetos de usuario. N(R): posicin del siguiente octeto que se espera recibir. Vlido si bit ACK activo. Lon Cab: longitud de la cabecera TCP, en mltiplos de 32 bits. Campo necesario porque la cabecera es de longitud variable.
27
Campos
Tam. Ventana: receptor anuncia sus recursos disponibles. Checksum: suma de comprobacin del segmento TCP y una pseudo-cabecera. Puntero Urgentes: indica la posicin dentro del segmento donde acaban los datos urgentes stos se hallan al principio. Vlido si bit URG activo. Opciones: Campo opcional de tamao variable. Define extensiones a TCP, tales como negociar el tamao mximo de segmento (MSS). Relleno: para que la cabecera sea mltiplo de 32 bits.
28
Clculo del Checksum

El Checksum se calcula sobre:
Pseudo-cabecera
Direcciones origen y destino de la cabecera IP Campo Protocolo de la cabecera IP Longitud de cabecera + datos TCP (en bytes)
Cabecera TCP Datos TCP
Se necesita saber la direccin IP origen, por lo que hay que interactuar con la entidad IP antes de enviar el datagrama.
29
La Pseudo-cabecera TCP
32 bits
Direccin IP de origen Direccin IP de destino
00000000 00000110
Long. Segmento TCP
Se aade al principio del segmento para el clculo del checksum. Permite a TCP comprobar que IP no se ha equivocado en la entrega del datagrama. El valor 1102 = 610 indica que el protocolo de transporte es TCP
30
Tipos de Flags
URG. Datos acelerados. El campo Puntero Urgentes tiene validez.
Ej: Envo de una seal a aplicacin remota
ACK. El campo N(R) es vlido. Confirmacin de entrega. PSH. El segmento requiere envo y entrega inmediata
Ej: Telnet requiere enviar lnea de buffer al presionar [Enter]
RST. Resetea la conexin ante un error irrecuperable. SYN. Establecimiento de conexin. Confirmacin con ACK. FIN. Liberacin de conexin. Confirmacin con ACK.
31
Transferencia de Datos
Se emplea ventana deslizante y asentimientos con memoria, que indican el siguiente octeto que se espera recibir. Cada segmento transmitido lleva asociado un temporizador. Cuando expira, se retransmite. El plazo de retransmisin se calcula dinmicamente para adaptarse a las condiciones de la red. El receptor recompone la ristra de datos de usuario, descartando duplicados, entregndolos en secuencia. Ms detalles en la siguiente seccin
32
Conexiones en TCP
Se utiliza saludo a tres vas (3-way handshake) tanto para establecer como para cerrar conexiones El proceso de establecimiento de conexin reserva recursos para la comunicacin e intercambia los nmeros de secuencia iniciales (ISN)
32 bits que se usan en el intercambio de datos de una conexin para identificar:
la posicin de los datos del segmento en el flujo de bytes del emisor el siguiente byte que espera el receptor
Se eligen de forma aleatoria a partir de un reloj para evitar que segmentos atrasados de conexiones anteriores puedan interferir en la conexin actual Con un MSL (Maximum Segment Lifetime) de unos 2 minutos, la probabilidad de que dos ISN coincidan es despreciable
33
Establecimiento de Conexin
TCP A
CLOSED SYN-SENT SYN-RECEIVED
Caso Normal
TCP B
LISTEN
Tiempo
ESTABLISHED
ESTABLISHED
Los primeros segmentos de una conexin TCP pueden llevar datos. En ese caso el TCP remoto los ha de retener hasta que la aplicacin receptora acepte la conexin.
Recuperacin
TCP A
CLOSED SYN-SENT
SYN Duplicado
TCP B
LISTEN
SYN-RECEIVED Tiempo
LISTEN SYN-RECEIVED
ESTABLISHED ESTABLISHED Arquitectura de Redes - Universidad de Murcia 35
Terminacin de la Conexin
La terminacin se hace de forma simtrica mediante un saludo a tres vas modificado
Cuando una parte no tiene ms datos que enviar enva un mensaje FIN que es asentido por el otro extremo Desconexin en cada sentido de comunicacin
Una vez terminada una conexin el host que inici la desconexin est un cierto tiempo a la espera por si aparecen segmentos retrasados
36
Desconexin en el Caso Normal

TCP A
ESTABLISHED FIN-WAIT-1 CLOSE-WAIT
TCP B
ESTABLISHED
FIN-WAIT-2 LAST-ACK TIME-WAIT
2*MSL CLOSED CLOSED
MSL: Maximum Segment Lifetime (normalmente 2 minutos)

Asentimiento de Mensajes sin Datos

Algunos mensajes (SYN, FIN) requireren asentimiento, pero no contienen datos
Los flags SYN y FIN cuando estn activos incrementan en 1 el nmero de secuencia (byte de datos virtual) La presencia del flag ACK no incrementa el nmero de secuencia
38
Diagrama de Estados
39
Opciones TCP
Opciones se suelen negociar en el segmento de inicio de la conexin
El que lleva el bit SYN activo
Algunas opciones comunes:

Factor de escala para ventanas de hasta 1 GB (RFC 1323). Mejora la eficiencia en redes LFN (Long Fat Network) con elevado valor de BW*RTT. Repeticin selectiva y acuse de recibo negativo (NAK) (RFC 1106).
40
Opciones TCP
MSS Maximum Segment Size (MSS)
Opcin ms comn, indica el tamao mximo del payload dispuesto a aceptar MSS pequeo poca eficiencia
Ej: si payload = 1 byte, slo 1/41 de carga til en TCP/IP
MSS grande
probabilidad de fragmentacin IP
si se pierde un fragmento, hay que retransmitir el segmento entero
Idealmente: MSS = Path MTU - TCPhdr IPhdr

Path MTU: MTU mnimo entre todos los enlaces del camino Path MTU Discovery (PMTUD), RFC 1191
Enva datagramas IP con MTU local y bit DF activo Reduce tamao si recibe mensaje ICMP Fragmentation Needed Problemas: filtrado de mensajes ICMP, PMTU para un datagrama puede diferir del siguiente, anticipacin de opciones IP y TCP Arquitectura de Redes - Universidad de Murcia 41
Mensajes de Keepalive
Cuando una conexin est inactiva durante un periodo de tiempo, expira el keepalive timer
del orden de 2 horas enva un segmento con el ltimo byte de datos asentido el extremo debe responder con un ACK, en cuyo caso la conexin sigue viva
Si no se recibe respuesta del otro lado

se repite el envo aprox. cada 1-2 minutos, hasta un mximo de aprox. 9 intentos si no se recibe respuesta se cierra la conexin
No requiere modificaciones en el TCP receptor
42
Mensajes de Keepalive
TCP A
Tiempo
100 bytes (501-600)
TCP B
Datos puestos en buffer para la aplicacin
Timer Keepalive
1 byte (600)
Datos duplicados descartados
43

45
Intercambio de Datos
TCP - Aplicacin
Aplicacin TCP: la aplicacin enva datos a TCP cuando quiere
Siempre y cuando TCP tenga espacio libre en el buffer de emisin
TCP Aplicacin: la aplicacin lee del buffer de recepcin de TCP cuando quiere y cuanto quiere
Excepcin: datos urgentes
Para TCP los datos de la aplicacin son un flujo continuo de bytes sin separacin alguna. La separacin de los datos (fin de registro, etc.) es responsabilidad de la aplicacin.
Aplicacin TCP Red

Intercambio de Datos
TCP - TCP
TCP manda los datos cuando quiere.
Excepcin: datos Pushed y Urgentes
TCP decide el tamao de segmento segn sus preferencias. Al inicio de la conexin se negocia el MSS. TCP puede aplicar la tcnica de Path MTU Discovery para ajustar el MSS al tamao ptimo para esa comunicacin. Normalmente TCP intenta agrupar los datos para que los segmentos tengan la longitud mxima, reduciendo as la sobrecarga debida a cabeceras y procesamiento de segmentos.
47
Segmentacin y Paquetizacin
Aplicacin
ABCD
ABC
TCP Red
ABCD
A B C D
48
Servicio de Flujo de Bytes

Host A
Host B
49
Emulado mediante Segmentos de Datos

Host A
Datos TCP
Segmento enviado cuando:

1. Buffer lleno (MSS bytes) 2. Expira temporizador 3. Son datos Pushed o Urg
Datos TCP
Host B
50
Nmeros de Secuencia
Host A
ISN (initial sequence number)
SN = primer byte
TCP Data
TCP HDR
ACK SN = siguiente byte esperado

TCP HDR
TCP Data
Host B
51
Ventanas Deslizantes
IP proporciona un servicio no confiable, por lo que pueden haber prdidas Para proporcionar un servicio de transporte confiable, TCP establece un temporizador de retransmisin para cada segmento Si se recibe un ACK para ese segmento se cancela el temporizador Cuntos segmentos consecutivos transmite TCP? Protocolo de ventana deslizante
El receptor anuncia la cantidad de bytes que puede recibir en su buffer El emisor transmite tanta informacin como puede (uso eficiente del canal) sin desbordar el buffer del receptor
52
Ventana Deslizante en TCP

Tamao de ventana
Datos asentidos
Datos enviados Datos que Datos que sin asentir pueden enviarse an no pueden enviarse
til para el emisor Receptor anuncia el tamao de ventana

normalmente 4KB 8KB - se anuncia al hacer la conexin, pero puede variar durante la misma
-
La poltica de retransmisin bsica es Go Back N

53
Resumen de Control de Flujo

El control de flujo se realiza mediante el anuncio del tamao de ventana que va en cada segmento Un TCP no debe retirar el crdito que ha asignado a su interlocutor. Si un TCP anuncia ventana 0 (cierra su ventana) el otro tiene que esperar. Excepciones:
Datos urgentes. Emisor puede enviar de vez en cuando (persistence timer) un segmento con un byte de datos. Si se ha perdido un segmento anunciando una ventana mayor que cero, podemos as evitar un bloqueo.
54
Transferencia Normal
TCP A
Tiempo
100 bytes (501-600)
200 bytes libres Datos ledos por la aplicacin 300 bytes libres Datos en buffer de aplicacin 100 bytes libres
Tras establecimiento
TCP B
200 bytes (601-800)
100 bytes (801-900)
Datos ledos por la aplicacin 300 bytes libres Datos puestos en buffer para la aplicacin 200 bytes libres
55
Prdida de Segmento de Datos

TCP A
Tiempo
100 bytes (501-600)
TCP B
400 bytes libres
200 bytes (601-800)
Datos ledos por la aplicacin 400 bytes libres
Retransm. timer
100 bytes (801-900)

Datos puestos en buffer para la aplicacin 100 bytes libres
56
Prdida de Asentimiento (W>0)

TCP A
Tiempo
100 bytes (501-600)
TCP B
300 bytes libres
Retransm. timer
200 bytes (601-800)
Datos ledos por la aplicacin 300 bytes libres
Cancela timer 100 bytes (801-900)
Datos ledos por la aplicacin 300 bytes libres Datos puestos en buffer para la aplicacin 200 bytes libres
57
Prdida de Asentimiento (W=0)

TCP A
Tiempo
300 bytes (401-700)
TCP B
300 bytes libres
Retransm. timer
100 bytes (701-800) ReTX timer 100 bytes (801-900)
Datos no ledos por la aplicacin 0 bytes libres
Duplicado, y buffer ledo por la aplicacin enva Dup ACK con W0
58
Prdida de Asentimiento (W=0)

TCP A
Tiempo
300 bytes (401-700)
TCP B
300 bytes libres
Retransm. timer
100 bytes (701-800) Cancela timer
Aplicacin lee 200 bytes 200 bytes libres
Datos guardados en buffer, dispon. 100 bytes
Qu ocurre si llega ACK con W=0 y se pierde ACK con W>0?

Temporizador de Persistencia
TCP A
Tiempo
100 bytes (501-600)
Buffer lleno
TCP B
Datos ledos por la aplicacin
Timer de Persistencia
Bloqueado
1 byte (601)
Almacena byte y devuelve ventana disponible
60
Eleccin del Tamao de Ventana

El tamao de ventana indica el mximo nmero de segmentos (o bytes) que pueden estar en la red sin recibir un asentimiento
W>1 permite mejorar la utilizacin del canal Ejemplo: Canal de b bits/s, segmentos de l bits y R segundos de RTT (asumimos tamao ACK << l)
Si W=1, la utilizacin del canal es l/(l+bR), <50% si l<bR Si W=2, la utilizacin del canal es 2l/(l+bR)
w=1 l/b w=2 l/b t=0 l/b t=l/b + R/2 t=l/b + R
61
Eleccin del Tamao de Ventana

No tiene sentido una ventana W>1 + bR/l
La fuente no puede enviar a ms de la capacidad del canal
En enlaces de baja capacidad, reducir los tamaos de los segmentos puede ayudar
62
Eficiencia de Ventana Deslizante

Round-trip time Tamao vent. Round-trip time Tamao vent. Tamao vent.
Host A
???
Host B
ACK (1) RTT > Tamao ventana
ACK ACK (2) RTT = Tamao vent.
63
Retransmisiones en TCP
Round-trip time (RTT) Retransmission TimeOut (RTO) Banda Guarda
Host A
RTT estimado
Dato1
Dato2
ACK Host B
ACK
TCP usa un timeout de retransmisin ajustable: Congestin RTT cambia Cambios en encaminamiento frecuentemente
64
Transferencia Interactiva
Receptor Lento
Emisor
Usuario teclea una C y TCP transmite inmediatamente TCP genera un ACK Servidor lee el carcter y lo escribe de nuevo. TCP enva el segmento. TCP genera un ACK
Receptor
Muy ineficiente! Cada carcter 4 segmentos Total: 162 B - tiles: 2 B
Funcionamiento de TCP en Telnet con eco remoto

Receptor Rpido
Emisor
Usuario teclea una C y TCP transmite inmediatamente Usuario teclea una O y TCP transmite inmediatamente TCP enva ACK de segmentos recibidos TCP entrega el dato a la aplicacin, la cul enva el carcter que es devuelto por TCP inmediatamente
Receptor
Tambin ineficiente Cada carcter 1 segmento (al menos)

Baja Eficiencia en TCP El funcionamiento eficiente de TCP aconseja enviar segmentos del tamao mximo permitido Cuando la aplicacin emisora genera los datos en pequeas dosis (p.ej: Telnet) se da un problema de eficiencia Solucin: Algoritmo de Nagle
67
Algoritmo de Nagle
Cuando la aplicacin enva datos en pequeos grupos, TCP enva el primero y retiene los dems hasta recibir el ACK; por cada ACK recibido enva un segmento con los bytes que hubiera pendientes, y as sucesivamente. Tambin se enva un segmento cuando los datos acumulados igualan el MSS o la mitad de la ventana.
El mecanismo es auto-regulado (self-clocking), pues cuanto ms cargada est la red mas tardarn los ACK y ms agrupados irn los datos Se puede aplicar a datos pushed en caso necesario
68
Algoritmo de Nagle
Ejemplo
Emisor
Usuario teclea una C y TCP transmite inmediatamente TCP espera ACK mientras usuario teclea ONTROL TCP enva datos en buffer al recibir ACK TCP entrega el dato a la aplicacin, la cul enva el carcter que es devuelto por TCP inmediatamente
Receptor

Sndrome de la Ventana Tonta

Baja Eficiencia en TCP
Sndrome de la ventana tonta
La aplicacin que enva datos los genera rpidamente La aplicacin receptora los recupera lentamente, un byte cada vez El buffer del TCP receptor se llena El TCP receptor notifica al emisor que su ventana est cerrada La aplicacin receptora lee un byte EL TCP receptor enva un ACK al emisor anunciado una ventana de 1 byte 7. El TCP emisor enva un segmento con 1 byte de datos 8. Volvemos al punto 3 1. 2. 3. 4. 5. 6.
Solucin: Solucin de Clark
70
Solucin de Clark
El TCP receptor solo debe notificar una nueva ventana cuando tenga una cantidad razonable de espacio libre. RFC 813 Razonable significa al menos:
Un MSS (segmento del tamao negociado), o La mitad del espacio disponible en el buffer
71
Algoritmo de Nagle vs Solucin de Clark

Ambos esquemas son complementarios y se usan conjuntamente
Algoritmo de Nagle (emisor): soluciona el problema causado por una aplicacin que escribe un byte a la vez Solucin de Clark (receptor): soluciona el problema causado por una aplicacin que lee un byte a la vez
En algunas situaciones el algoritmo de Nagle puede provocar un comportamiento no deseado

P.ej. sesin X11 donde el puntero se mueve de forma abrupta
Para la solucin de Clark hay dos posibles implementaciones

No anunciar una ventana mayor hasta que no se llega al lmite mnimo, pero s enviar ACKs por cada segmento de datos Atrasar los ACKs (Delayed ACK) durante un tiempo de espera (norm. 200 ms), anunciando entonces la nueva ventana
Delayed ACK
Ventajas
Decrece el trfico de control en la red: si llegan N segmentos durante el tiempo de espera, slo enviamos 1 ACK como respuesta en lugar de N+1 Mayor probabilidad de hacer piggybacking con datos enviados En el mismo ACK se anuncia la nueva ventana del receptor (Clark), en lugar de enviar primero el ACK y luego la ventana
Inconvenientes
Si el ACK se atrasa demasiado tiempo, podra provocar la retransmisin del segmento por parte del emisor consumo de ancho de banda y procesamiento TCP usa ACKs para estimar RTTs y tiempos de retransmisin Delayed ACKs podran confundir los estimadores
Recomendados por el estndar, con unas limitaciones

No se puede atrasar un ACK ms de 500 ms Al menos 1 de cada 2 segmentos provocan ACK inmediato

74
Contextualizacin
En esta seccin nos centramos en el control de congestin en TCP
Additive Increase, Multiplicative Decrease (AIMD) Slow Start Congestion Avoidance Algoritmo de Karn para estimacin de timers de retransmisin
Control de Flujo
Control de Congestin
75
La Congestin es Inevitable
Es incluso buena! Usamos conmutacin de paquetes porque hace un uso eficiente de los enlaces. Por tanto, los buffers de los routers estn normalmente ocupados. Si los buffers estn siempre vacos, el retardo es bajo, como el uso de nuestra red. Si los buffers estn siempre ocupados, el retardo es ms alto, pero estamos usando las red muy eficientemente.
Cunta congestin es demasiada?

Problemas de la Congestin
Si el retardo es demasiado alto, afecta negativamente al rendimiento de las aplicaciones. Si los buffers de los routers se llenan, existe prdida de paquetes (retardo = ).
Comportamiento tpico de colas con llegadas aleatorias: Las rfagas mueven la asntota a la izquierda Una mtrica simple para medir cmo de bien funciona la red:
Potencia =
Carga Retardo
Retardo medio
Potencia
Carga
carga Carga ptima

77
Congestin y TCP
Colapso por Congestin
Congestin en la red Mayor Retardo
TCP retransmite segmento
TCP expira timer de retransmisin
TCP detecta la congestin cuando se pierde un segmento (expira timer de retransmisin) TCP alivia la congestin reduciendo la tasa de envo TCP intenta evitar la congestin aumentando poco a poco la tasa de envo, hasta detectar congestin
Ventana de Congestin
Las fuentes TCP cambian la tasa de envo modificando el tamao de la ventana:
Window = min{Advertized window, Congestion Window}
Receptor (rwnd) Emisor (cwnd)
Es decir, enva a la velocidad del componente ms lento: el receptor, o la red. cwnd se incrementa de forma aditiva, y se decrementa de forma multiplicativa (AIMD)
AI, Slow Start: Recibir 1 ACK +1 MSS a cwnd MD: Perder 1 segmento (timeout) /2 tamao de cwnd
79
Slow Start
Diseado para averiguar la tasa de datos apropiada al inicio de una conexin, o tras haber detectado congestin Inicialmente:
cwnd = 1 MSS
Por cada segmento enviado con xito (ACK recibido) la ventana se ampla en 1 MSS
cwnd += 1 MSS En la prctica esto supone un crecimiento exponencial en potencias de dos
Si la ventana de congestin supera a la de control de flujo, se aplica la de flujo (rwnd), por lo que cwnd deja de crecer
80
Slow Start
No es tan lento
Slow Start no es slow en absoluto
cwnd crece de forma exponencial se le llama as porque inicialmente TCP no tena control de congestin la fuente hubiera enviado una ventana rwnd completa de datos 1 2 4 8
Fuente
D D
A A
D D
D A
D A A A
Destino
81
Actuar ante Congestin

Deteccin de Congestin
Expira un timer de retransmisin se retransmite el segmento se ha perdido un segmento
Control de la Congestin
Se fija un valor umbral (ssthresh) en un valor igual a la mitad de la cwnd que haba cuando se produjo la prdida
ssthresh = cwnd / 2 Inicialmente, ssthresh = tamao mximo de ventana (64 KB por defecto); o ssthresh = rwnd; u otro criterio dependiente de la implementacin
La ventana de congestin vuelve a su valor inicial

cwnd = 1 MSS
La cwnd crece como antes hasta el umbral ssthresh

Ejecutamos Slow Start
82
Congestion Avoidance
Una vez se alcanza el umbral (cwnd == ssthresh), ejecutamos algoritmo de congestion avoidance.
Slo se incrementa la ventana a razn de 1 MSS por cada rfaga (ventana) que se recibe correctamente. Motivacin:
1. Detectamos congestin, as que comenzamos de nuevo a transmitir con Slow Start desde el principio. 2. Al llegar a la mitad de la ventana que caus la congestin, aumentamos ms lentamente la tasa de envo para evitar entrar de nuevo en congestin (Congestion Avoidance). 3. Si en cualquier punto se vuelve a detectar la congestin, repetimos el proceso.
83
Ejemplo
Slow Start
Ventana 1 MSS 2 MSS
Emisor
SEG 1
Receptor
ACK 1 SEG 2 SEG 3 SEG 4 SEG 5 SEG 6 SEG 7 ACK 2 ACK 3 ACK 4 ACK 5 ACK 6 ACK 7
Con MSS = 1KB en 7 iteraciones se llega a 64 KB, tamao mximo de la ventana
4 MSS
8 MSS
SEG 8 SEG 9 ACK 8 SEG 10 ACK 9 SEG 11 ACK 10 SEG 12 ACK 11 SEG 13 ACK 12 SEG 14 ACK 13 SEG 15 ACK 14 ACK 15
84
Ejemplo
Deteccin, Slow Start y Congestion Avoidance
Ventana 1 MSS 2 MSS
Emisor
SEG 16
Receptor
ACK 16 SEG 17 SEG 18 SEG 19 SEG 20 SEG 21 SEG 22 SEG 23 SEG 24 SEG 25 SEG 26 SEG 27 SEG 28 SEG 29 SEG 30 SEG 31 SEG 32 SEG 33 ACK 17 ACK 18
Segmento 15 perdido y retransmitido
4 MSS
ssthresh = 4KB
ACK 19 20 ACK ACK 21 ACK 22 ACK 23 ACK 24 ACK 25 ACK 26 ACK 27 ACK 28 ACK 29 ACK 30 ACK 31 ACK 32 ACK 33
85
5 MSS
6 MSS
Algoritmo
Slow Start y Congestion Avoidance
Nota: usamos el segmento como unidad, en la prctica se usan bytes Inicializacin: cwnd = 1 ; ssthresh = rwnd ; Al recibir ack: if (cwnd < ssthresh) /* Slow Start */ cwnd = cwnd + 1 ; else /* Congestion Avoidance */ cwnd = cwnd + 1/cwnd; Al ocurrir un timeout de retransmisn: send snd_una ; ssthresh = max(2, cwnd / 2) ; cwnd = 1 ;
86
Control de Congestin en TCP

20 Congestion Avoidance ssthresh 15 Ventana de Congestin 10 Slow Start Congestin Detectada
ssthresh
0 Mensajes Enviados
Copyright 2000 The McGraw Hill Companies Leon-Garcia & Widjaja: Communication Networks Figure 7.63
87
Timer de Retransmisin
RTO
RTO (Retransmission TimeOut) debe ser adecuado para la comunicacin:
Si es excesivo se esperar innecesariamente. Si es muy corto se harn reenvos innecesarios.
Idealmente debe ser un poco superior al Round Trip Time (RTT), pero este valor es difcil de predecir extremo a extremo debido a su gran fluctuacin.
Por tanto, se deben utilizar mecanismos dinmicos autoadaptables. TCP actualiza el RTO en base a una estimacin del RTT segn el tiempo que pasa desde que se enva un segmento hasta que se recibe el ACK correspondiente.
La estimacin del RTO es crucial para el correcto funcionamiento del Control de Congestin en TCP.
Efecto del RTO en el Control de Congestin
89
Estimacin de RTT y RTO

Propuesta Inicial
Usamos una media ponderada del RTT (MRTT) como estimador del RTT real: MRTTn = MRTTn-1 + (1 - ) RTT
donde RTT: Valor ms reciente medido de RTT : Factor de amortiguacin, normalmente 0.9
Deducir el RTO a partir de MRTT es complicado si no tenemos una idea de la dispersin de los valores.
Inicialmente se propuso: RTO = * MRTTn, con un factor constante =2. Jacobson demostr que este esquema no es capaz de absorber grandes fluctuaciones de RTT.
90
Varianza del RTT

Debe haber una (desconocida) distribucin de los RTTs. Intentamos estimar el RTO para minimizar la probabilidad de un falso timeout.
Probabilidad
Las colas de los routers crecen con la carga hasta ser inestables. Al aumentar la carga, la varianza del retardo crece rpidamente.
Retardo medio de la cola
La varianza crece rpido con la carga
varianza
media
RTT
Carga
(Volumen de trfico que llega al router)
91
Estimacin de RTO
Propuesta Mejorada
Propuesta de Jacobson
Estimar el RTT medio como antes, calculando MRTT. Estimar tambin la desviacin tpica D del RTT Se pueden calcular de forma eficiente a partir de las siguientes ecuaciones: Err = RTT MRTT MRTTn = MRTTn-1 + g*Err Dn = Dn-1 + h*(|Err| - Dn-1)
donde: g = 1/8 es la ganancia del estimador de la media, h = 1/4 es la ganancia del estimador de la desviacin tpica.
El RTO se hace proporcional a la desviacin estimada D, en lugar de a la constante . RTO = MRTT + *D , donde = 4.
Estimacin de RTO
N 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 230,00 238,00 241,25 253,59 252,64 246,19 257,92 259,68 266,10 268,09 265,33 270,16 274,89 269,28 MRTTn-1 RTTn 230 294 264 340 246 201 340 272 311 282 246 304 308 230 328 MRTTn 230,00 238,00 241,25 253,59 252,64 246,19 257,92 259,68 266,10 268,09 265,33 270,16 274,89 269,28 276,62 64 54,5 65,56 51,07 51,21 61,86 49,92 50,27 41,68 36,78 37,25 37,40 39,27 64 54,5 65,56 51,07 51,21 61,86 49,92 50,27 41,68 36,78 37,25 37,40 39,27 44,13 494 459,25 515.83 456.92 451.27 505.36 459,36 467,18 434,81 412,45 419,16 424,49 426,36 453,14 Dn-1 Dn RTO
Evolucin de MRTT, D y RTO en funcin del valor de RTT

Estimar RTT ante Retransmisiones

Host A Host B Host A Host B
Retransmission Muestra incorrecta del RTT Muestra incorrecta del RTT
Retransmission
Problema:
Cmo estimar el RTT cuando se retransmiten segmentos?
Soluciones:
Algoritmo de Karn - Opcin de Timestamp
-
94
Algoritmo de Karn
Al recibir un ACK de un segmento que se retransmiti:
No modificar el MRTT estimado. Duplicar el RTO.
Por qu se duplica el RTO?

1. Puede que haya habido un fuerte aumento del retardo en la red. 2. Como no usamos el ACK para actualizar el MRTT, el valor de RTO permanecera igual, siendo ms pequeo que el retardo real de la red. 3. Lo anterior ocasionara la retransmisin de todos los segmentos subsiguientes, con lo que nunca se actualizaran las estimaciones de MRTT y RTO. Duplicando el RTO con cada retransmisin, se converger a una solucin en que RTO > RTT, por lo que se volvern a tener muestras para estimar MRTT y RTO.
Algoritmo de Karn
Inicializacin: MRTT=0; RTO = 3 + 2D; Llegada de ACK: Si (ACK == Segmento Retransmitido) { RTO = RTO * 2; /* Por cada ACK recibido */ /* No se modifica MRTT */ } Si (Primer ACK de Segmento No Retransmitido) { Err = RTT - MRTT ; MRTT = MRTT+g*Err; D = D + h(|Err| - D) RTO = MRTT + 4*D }
TCP Timestamp Option

RTTM: Round-Trip Time Measurement, RFC 1323. Los host que soportan esta opcin, envan una marca de tiempo (timestamp) al iniciar la conexin (SYN). Si el otro extremo de la conexin tambin la incluye, el resto de segmentos pueden ir etiquetados con el timestamp. Los ACK incluyen el timestamp original del segmento de datos. Desaparece el problema de ambigedad con los segmentos retransmitidos:
Al recibir el ACK, RTT = Reloj Actual - Timestamp
97

98
Retransmisin Bsica
Problemas Incluso si la estimacin del RTT es buena
Si el RTO no es suficiente, muchos segmentos se envan de forma repetida.
Emisor
Es posible un compromiso entre estar seguros de evitar el primer caso con un valor alto de RTO, Receptor y a la vez detectar las prdidas rpidamente? Si el RTO es muy grande, la retransmisin ocurre muy tarde.
Emisor
Receptor
Retransmisin Bsica
Escenario
Un receptor debe enviar un ACK inmediatamente al recibir un segmento fuera de orden. El emisor recibe una serie de ACK duplicados que se pueden usar para inferir la prdida del segmento. Cuntos para distinguir prdida de desorden?
Fast Retransmit
Un ACK Duplicado es aqul que asiente un segmento de datos ya asentido (mismo nmero de secuencia) Idea bsica: Usar ACKs duplicados para detectar prdida de segmentos
La red podra entregarlos fuera de orden, por lo que el emisor infiere que el segmento se ha perdido cuando llegan mltiples duplicados
Fast Retransmit
Con la recepcin de tres ACKs duplicados, el emisor TCP retransmite el segmento perdido antes de que expire el RTO.
101
Algoritmo
SS y CA con Fast Retransmit
Nota: usamos el segmento como unidad, en la prctica se usan bytes Inicializacin: cwnd = 1 ; ssthresh = rwnd ; Al recibir ack: if (cwnd < ssthresh) /* Slow Start */ cwnd = cwnd + 1 ; else /* Congestion Avoidance */ cwnd = cwnd + 1/cwnd; Al ocurrir un timeout de retransmisn o recibir 3 DupACK: send snd_una ; ssthresh = max(2, cwnd / 2) ; cwnd = 1 ;
102
Fast Retransmit
Generalmente, Fast Retransmit elimina alrededor de la mitad de las retransmisiones por expiracin del RTO.
Esto supone alrededor del 20% de mejora en el throughput. Ntese que si la ventana efectiva es pequea, fast retransmit no puede eliminar todos los timeouts si no le queda crdito disponible.
Tras la retransmisin, la ventana de congestin se reduce a 1 y se comienza con Slow Start de nuevo.
Si estn llegando ACKs duplicados, puedo inferir algo del nivel de congestin actual de la red?
Fast Recovery
Idea bsica: Si llegan ACKs Duplicados, significa que otros segmentos estn llegando.
La congestin no es excesiva. Podramos recuperarnos a partir de una tasa intermedia en lugar de bajar cwnd a 1 segmento.
Fast Recovery
Tras Fast Retransmit, dividir la cwnd a la mitad y comenzar la recuperacin desde este punto usando incremento aditivo.
Fast Retransmit con Fast Recovery

Fast Retransmit
Cuando el emisor recibe 3 ACKs Duplicados, asume que el segmento se perdi. Reduce el umbral ssthresh a la mitad de cwnd, retransmite el segmento perdido, y pasa a Fast Recovery.
Fast Recovery
El emisor reduce la ventana de congestin al valor de ssthresh ms 3 segmentos.
Los correspondientes a los DupACK, puesto que ya han salido de la red y no consumen recursos.
Por cada DupACK adicional recibido, cwnd += 1 MSS. Sigue enviando segmentos nuevos (si lo permite la ventana efectiva). Al recibir un ACK que asiente nuevos datos, cwnd = ssthresh y comienza Congestion Avoidance (no se entra en Slow Start).
Algoritmo
Fast Retransmit y Fast Recovery
Nota: usamos el segmento como unidad, en la prctica se usan bytes Al recibir DupACK: if (third dup ack) { /* Fast ReTx */ ssthresh = max (2, cwnd / 2) ; send snd_una ; cwnd = ssthresh + 3 ; fast_recovery = true ; } else if (fast_recovery) /* Fast Recovery */ cwnd = cwnd + 1; Al recibir ACK: fast_recovery = false ; cwnd = ssthresh ; /* Entramos en Congestion Avoidance */
106
Ejemplo
Estado inicial cwnd=7 Slow Start
0 1 2 3 4 5 6 cwnd=8 7 8 1 cwnd=8 cwnd=9 9 Ack(9) Ack(10) cwnd=10 10 cwnd=11 11 Ack(1) Ack(1) Ack(1) Ack(1) Ack(1) Ack(1) Ack(1) Ack(1)
Fast Retransmit cwnd=8/2+3=7 ssthresh=8/2=4 Fast Recovery
Sale de Fast Recovery cwnd=ssthresh=4 Congestion Avoidance
12
107
Ejemplo
108

109
Contextualizacin
Hemos estudiado diferentes mejoras que se han ido introduciendo a TCP para un mejor soporte de la congestin:
Slow Start Congestion Avoidance Fast Retransmit Fast Recovery
En general, las diferentes versiones de TCP que se han estandarizado, incluyen diferentes combinaciones de estos componentes. En esta seccin, estudiaremos la evolucin histrica de las diferentes versiones de TCP y compararemos las caractersticas de las mismas.
Variantes de TCP
TCP inicial (RFC 793) TCP Tahoe (RFC 1122) TCP Reno (RFC 2581) TCP NewReno (RFC 2582) TCP SACK (RFC 2018) Otras variantes
TCP Vegas: Mejoras a la estimacin de congestin. TCP FACK: Forward ACK.
111
TCP Tahoe
Slow Start con Congestion Avoidance Cuando emisor recibe 3 DupACKs para el mismo nmero de secuencia o expira el RTO, infiere una prdida
Se reduce la ventana de congestin a 1 segmento Se comienza de nuevo Slow Start Slo se retransmite al expirar el RTO
Ventajas:
Simple
Inconvenientes:
Control de congestin demasiado agresivo
112
TCP Tahoe
Nota: usamos el segmento como unidad, en la prctica se usan bytes Inicializacin: cwnd = 1 ; ssthresh = rwnd ; Al recibir ack: if (cwnd < ssthresh) /* Slow Start */ cwnd = cwnd + 1 ; else /* Congestion Avoidance */ cwnd = cwnd + 1/cwnd; Al ocurrir un timeout de retransmisn o recibir 3 DupACK: if (timeout or (DupAck and Fast ReTx)) send snd_una ; ssthresh = max(2, cwnd / 2) ; cwnd = 1 ;
TCP Tahoe
114
TCP Tahoe
115
TCP Tahoe con Fast Retransmit
116
TCP Tahoe con Fast Retransmit
117
TCP Reno
El problema de TCP Tahoe es la agresividad del control de congestin En Reno las prdidas se siguen detectando mediante expiraciones del RTO y DupACKs. En esta variante, se implementan Fast Retransmit y Fast Recovery.
Slo se usa Slow Start si la prdida se detect por RTO
Ventajas:
Reno aumenta el rendimiento de Tahoe al usar Fast Recovery
Inconvenientes:
Puede funcionar mal cuando hay mltiples prdidas
TCP Reno
Nota: usamos el segmento como unidad, en la prctica se usan bytes Al recibir DupACK: if (third dup ack) { /* Fast ReTx */ ssthresh = max (2, cwnd / 2) ; send snd_una ; cwnd = ssthresh + 3 ; fast_recovery = true ; } else if (fast_recovery) /* Fast Recovery */ cwnd = cwnd + 1; Al recibir ACK: fast_recovery = false ; cwnd = ssthresh ; /* Entramos en Congestion Avoidance */
119
TCP Reno
Fast Recovery
120
TCP Reno
Problemas
Si cwnd < 4 segmentos entonces no pueden obtenerse 3 DupACKs y el temporizador RTO saltar siempre. Si se pierden mltiples mensajes de la misma ventana de datos, no se detecta con los DupACKs por lo que saltar el RTO. El algoritmo no gestiona prdidas de paquetes durante la fase de Fast Recovery (no recursivo), por lo que acabar saltando el RTO.
En todos los casos, sufrimos el retardo de expiracin y el inicio lento de Slow Start.
121
TCP Reno
Emisor
Flight Size =Num. de segmentos sin asentir Fast Retransmit cwnd=8/2+3=7 ssthresh=8/2=4 Fast Recovery
0 1 2 3 4 5 6 cwnd=8 7 8 1 Ack(3) cwnd=8 cwnd=9 9 Ack(3)
Ejemplo
Receptor
Ack(1) Ack(1) Ack(1) Ack(1) Ack(1) Ack(1)
El algoritmo no sabe qu segmentos enviados han llegado
Exit Fast Recovery cwnd=ssthresh=4 Congestion Avoidance Flight Size > cwnd 8 y 9 estn fuera de la cwnd, si se pierden: RTO
Y si se pierde este mensaje?
122
TCP Reno
Prdidas Mltiples
123
TCP NewReno
Idea bsica: Si el emisor anota el nmero mayor de segmento enviado al entrar en Fast Recovery (recover), al llegar un ACK no duplicado puede ver si se trata de un ACK Parcial, indicando que se han perdido ms paquetes de la ventana [Hoe95]. En ese caso, el emisor retransmite tambin el siguiente segmento perdido, y permance en la fase de Fast Recovery. El emisor termina la fase de Fast Recovery cuando recibe un ACK con nmero de secuencia recover+1.
124
TCP NewReno
Algoritmo
Si recibido Ack Parcial (seqnum < recover)
Retransmitir el primer segmento no asentido cwnd = cwnd - Bytes Asentidos + MSS Si nuevo cwnd lo permite, mandar un nuevo segmento
No salir de Fast Recovery

Por cada DupACK adicional que llegue
cwnd += MSS
La reducin de cwnd al llegar el ACK Parcial intenta garantizar que al acabar Fast Recovery haya aproximadamente ssthresh bytes sin asentir en la red
Mantener el self-clocking
125
TCP NewReno
Ejemplo
Fast Retransmit cwnd=6/2+3=6 ssthresh=6/2=3 Recover=6 Fast Recovery
Emisor
0 1 2 3 4
Receptor
Ack(1) Ack(1) Ack(1) Ack(1) Ack(1)
cwnd=6 5 6
1 cwnd=7 7
Ack(3) Ack(3)
Recover Ack Partial Ack 3 cwnd=7-(3-1)+1=6 cwnd=7 8 Recover < Ack Exit Fast Recovery cwnd=ssthresh=3 Congestion Avoidance Arquitectura de Redes - Universidad de Murcia
Ack(8) Ack(9)
126
TCP Reno vs TCP NewReno
127
TCP SACK
RFC 2018 y 2883
Los asentimientos acumulativos no dan mucha informacin sobre qu paquetes han llegado al receptor
Un emisor agresivo podra retransmitir muy pronto segmentos ya entregados
Selective Acknowledgements (SACK)

Usar campos de opciones TCP para indicar al emisor (con bloques SACK) qu segmentos se han recibido El emisor puede centrarse en enviar los segmentos perdidos cuando corresponda
Mismos mecanismos de control de congestin que en Reno No se puede ir ms all de cwnd
Cada vez que sucede un timeout, se descarta la informacin SACK recibida

Un receptor puede desechar datos previamente asentidos selectivamente (SACKed)
Para Usar SACK

Se negocia el uso en los mensajes SYN
Opcin SACK Permitted
Kind(1)=4 len(1)=2
Activa el uso de ACK selectivos
Se manda en los ACKs la opcin TCP SACK
Kind(1)=5 Borde izq(4) Borde izq(4)
len(1) Borde der(4) Borde der(4)
4 bloques como mximo 3 bloques si se usa opcin timestamp

129
TCP SACK
Ejemplo Supongamos que se transmiten los segmentos 525 Supongamos que se pierden el 5, 12, y 18
El receptor enva un ACK=5, y SACK=(6-11,13-17,1925) En las siguientes transmisiones que correspondan, el emisor se centrar en transmitir los segmentos 5, 12, y 18
Importante: Prevalecen las reglas de control de congestin de TCP Reno

Mantiene el self-clocking
130
TCP SACK
131
Otras Variantes de TCP

TCP Vegas
Usa el RTT como un indicador rpido de posible congestin Reduce prdidas como consecuencia de prevenir congestin Reduce la tasa antes de que los mensajes empiecen a ser descartados Si crece el RTT; reducir la tasa y variacin de la ventana de congestin Problema: Con otros flujos en la red, sale perdiendo la equidad
TCP FACK
Mejora adicional de la informacin de las opciones SACK para mejorar el mecanismos de control de congestin
132
Bibliografa
Bsica
Tanenbaum, secc. 3.4, 6.1-6.4. Comer, cap. 12 y 13. Bertsekas, secc. 6.1-6.2.
Complementaria
Peterson, cap. 5 y 6. Stevens Vol I, cap. 17 y 18. Stallings, cap. 20.
133
Bibliografa
[Fall95] Fall, K. and Floyd, S., "Comparisons of Tahoe, Reno, and Sack TCP", ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z, December 1995. [Hoe95] J. Hoe, Startup Dynamics of TCP's Congestion Control and Avoidance Schemes. Master's Thesis, MIT, 1995. [RFC2581] Stevens, W., Allman, M. and V. Paxson, "TCP Congestion Control", RFC 2581, April 1999. [RFC2018] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, TCP Selective Acknowledgement Options, RFC 2018, October 1996.
134

Ar Tema4

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Ar Tema4

Загружено:

Авторское право:

Доступные форматы

1908 Arquitectura de Redes

Tema 4. Aspectos Avanzados del Protocolo TCP

Pedro M. Ruiz <pedrom@um.es>

Francisco J. Ros <fjros@um.es>

3 Grado en Ingeniera Informtica 2011/2012

Organizacin del tema

Arquitectura de Redes - Universidad de Murcia

Organizacin del tema

Arquitectura de Redes - Universidad de Murcia

Arquitectura de Redes - Universidad de Murcia

Source: CS244, Steve McKeown, Stanford University

Introduccin al Nivel de Transporte

Elementos Principales del Nivel de Transporte

Establecimiento y cierre de conexiones

Control de flujo y buffers

Control de Flujo, Congestin y Errores

La carga ofrecida a la red puede ser superior a la mxima soportada

Algunas sesiones podran recibir muchos ms recursos que otras

Una subred puede perder o retrasar mensajes

Arquitectura de Redes - Universidad de Murcia

Comparacin de Protocolos de Transporte en Internet

Arquitectura de Redes - Universidad de Murcia

Organizacin del tema

Arquitectura de Redes - Universidad de Murcia

Nivel de transporte (TCP)

Nivel de red (IP)

Nivel de enlace (Ethernet)

Arquitectura de Redes - Universidad de Murcia

URG: ACK: PSH: RST: SYN: FIN:

Arquitectura de Redes - Universidad de Murcia

Arquitectura de Redes - Universidad de Murcia

Arquitectura de Redes - Universidad de Murcia

Clculo del Checksum

Cabecera TCP Datos TCP

Arquitectura de Redes - Universidad de Murcia

Long. Segmento TCP

Arquitectura de Redes - Universidad de Murcia

Arquitectura de Redes - Universidad de Murcia

Arquitectura de Redes - Universidad de Murcia

Arquitectura de Redes - Universidad de Murcia

ESTABLISHED ESTABLISHED Arquitectura de Redes - Universidad de Murcia 35

Arquitectura de Redes - Universidad de Murcia

Desconexin en el Caso Normal

FIN-WAIT-2 LAST-ACK TIME-WAIT

2*MSL CLOSED CLOSED

MSL: Maximum Segment Lifetime (normalmente 2 minutos)

Asentimiento de Mensajes sin Datos

Arquitectura de Redes - Universidad de Murcia

Arquitectura de Redes - Universidad de Murcia

Algunas opciones comunes:

Arquitectura de Redes - Universidad de Murcia

si se pierde un fragmento, hay que retransmitir el segmento entero

Idealmente: MSS = Path MTU - TCPhdr IPhdr

Si no se recibe respuesta del otro lado

No requiere modificaciones en el TCP receptor

Arquitectura de Redes - Universidad de Murcia

Datos duplicados descartados

Arquitectura de Redes - Universidad de Murcia

Organizacin del tema

Arquitectura de Redes - Universidad de Murcia

Aplicacin TCP Red

Arquitectura de Redes - Universidad de Murcia

Arquitectura de Redes - Universidad de Murcia