I. ARQUITECTURA TCP/IP 1. Protocolo IPv6 (ICMPv6) 2. IP móvil en

ARQUITECTURA DE REDES DE COMUNICACIONES
ÍNDICE TEMÁTICO
I. ARQUITECTURA TCP/IP
1. Protocolo IPv6 (ICMPv6)
2. IP móvil en IPv4 e IPv6
3. Transición de IPv4 a IPv6
4. Encaminamiento dinámico de unidifusión y MPLS
5. Multidifusión IP
6. Encaminamiento dinámico de multidifusión
7. TCP: Servicios opcionales (confirmación selectiva o SACK)
y control de la congestión
UDP: Servicio no orientado a conexión para transmisiones multimedia
en tiempo real
8. Parámetros de calidad de servicio, modelos de calidad de servicio
y multimedia en tiempo real (RTP y VoIP)
II. SERVICIOS Y TECNOLOGÍAS DE SEGURIDAD EN INTERNET
1. Amenazas, servicios y mecanismos de seguridad
2. Seguridad Web y correo electrónico
3. Protección de las comunicaciones: Intranets y Redes privadas virtuales
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
1
Arquitectura de Redes de Comunicaciones
Documentación: Tema I, Capítulo 7
http://pegaso.ls.fi.upm.es/arquitectura_redes/index2.html
material
TRANSPARENCIAS
http://halley.ls.fi.upm.es/~jyaguez/libros.html
PROBLEMAS
http://halley.ls.fi.upm.es/~jyaguez/examenes.html
•TCP/IP Tutorial and Technical Overview, Lydia Parziale, David T. Britt ,…
8ª edición (Diciembre 2006).
Redbooks: http://www.redbooks.ibm.com/portals/solutions
Libro descargable desde Internet)
.Los RFCs que se indiquen
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
2
LOS RFC de TCP
http://www.rfc-editor.org/rfcsearch.html
 RFC-793 Transmission Control Protocol, Darpa Internet
Program Protocol Specification, septiembre 1981
 RFC-1323 TCP Extensions for High Performance, 1992
Aumento de la ventana de recepción hasta 32 bits
 RFC-2018 TCP Selective Acknowledgment Option, 1996
Confirmación selectiva
 RFC-5681 TCP Congestion Control, 1999
Algoritmos para control de congestión:
• Comienzo lento (Slow Start)
• Prevención de congestión (Congestion Avoidance)
• Retransmisión rápida (Fast Retransmit)
• Recuperación rápida (Fast Recovery)
 RCF-3782 The New Reno Modification to TCP's Fast Recovery
Algorithm, 1999
ARQUITECTURA Y SERVICIOS DE INTERNET
© Fco. Javier Yágüez García
3
NIVELES SUPERIORES TCP/IP
NIVELES
SUPERIORES
NIVELES
SUPERIORES
SISTEMA FINAL
EXTREMO A EXTREMO
SISTEMA FINAL
APLICACIÓN
APLICACIÓN
EXTREMO A EXTREMO
TCP/UDP
TCP/UDP
IP
INTERFAZ DE
RED
INTERFAZ
DE RED
INTERFAZ
DE RED
INTERFAZ
DE RED
INTERFAZ
DE RED
ROUTER
(SISTEMA INTERMEDIO)
INTERFAZ DE
RED
WiFi
Ethernet
NIVELES
INFERIORES
IP
IP
IP
ROUTER
(SISTEMA INTERMEDIO)
NIVELES
INFERIORES
Las unidades de datos del protocolo TCP (“PDUs TCP”) se denominan segmentos TCP
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
4
NIVEL DE TRANSPORTE
PROTOCOLO TCP (Transmission Control Protocol)
SERVICIOS OPCIONALES (SACK)
Y CONTROL DE LA CONGESTIÓN
CONTROLES
SISTEMA FINAL
EXTREMO A EXTREMO
APLICACIÓN
SISTEMA FINAL
APLICACIÓN
ORIENTADO A LA CONEXIÓN
(control de errores y flujo) y CONGESTIÓN
TCP
ROUTER
IP
ROUTER
…
IP
INTERFAZ DE
RED
INTERFAZ
DE RED
Ethernet
TCP
INTERFAZ
DE RED
INTERFAZ
DE RED
…
IP
IP
INTERFAZ
DE RED
INTERFAZ DE
RED
Ethernet
TCP aparte ofrece como servicios básicos: Un servicio de flujo de octetos,
orientado a la conexión, multiplexado y dúplex
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
5
Control de Errores TCP
RECORDATORIO
 Equivalente al control de errores en el nivel de enlace
 Con la diferencia de que TCP CONTROLA OCTETOS DE
DATOS PERDIDOS, DESORDENADOS Y DUPLICADOS y
NO las unidades de datos o segmentos TCP que transportan
dichos octetos de datos
 Los segmentos de datos no se numeran sólo los octetos de
datos
 CADA OCTETO DE DATOS DISPONE DE UN NÚMERO
DE SECUENCIA
 A su vez, el CAMPO DE DATOS o los OCTETOS DE DATOS
de cada segmento de información tiene asociado
 Una confirmación
 Un temporizador de espera de confirmación
• Al vencimiento sin confirmación se produce una
retransmisión
ARQUITECTURA Y SERVICIOS DE INTERNET
© Fco. Javier Yágüez García
6
Filosofía Operativa TCP
RECORDATORIO
 Todo proceso de aplicación montado sobre TCP
se despreocupa de delimitar sus mensajes
 TCP trata los mensajes , pasados por el proceso
de aplicación, como un flujo o “chorro” de
octetos (byte-stream) que recoge, numera,
almacena y agrupa en segmentos en función de
la MTU de salida
 Por esta razón, TCP no numera los segmentos
sino los octetos de datos transmitidos
 A su vez, las confirmaciones, por parte de la
entidad receptora TCP, reconocen octetos de
datos correctamente recibidos y no segmentos
recibidos
ARQUITECTURA Y SERVICIOS DE INTERNET
© Fco. Javier Yágüez García
7
Control de Flujo TCP
RECORDATORIO
 Equivalente al control de flujo en el nivel de enlace
MECANISMO DE VENTANA DESLIZANTE
• WT y WR
Con la diferencia de que TCP SÓLO DISPONE DE
UN
• BUFFER DE TRANSMISIÓN en donde
almacena una copia de los octetos de datos
enviados y no confirmados
• BUFFER DE RECEPCIÓN en donde almacena
los octetos de datos que, en un momento dado, el
receptor puede aceptar en función de su número
de secuencia
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
8
1 2 3 4 5 6 7 8 910 11 12 1314 1516 17 18
Numeración TCP de los octetos del mensaje
Miguel hola un saludo
UN EJEMPLO DEL CONTROL DE ERRORES TCP
(EMISOR)
Javier
A
DATOS DE USUARIO
hola
un
Miguel hola
un
saludo
Segmenta y numera los octetos
13 saludo
TCP
11
hola
Protocolo
de Aplicación “P”
(CABECERA)
un
IP
A31
RED de Acceso
A21
un
R31
R21 B32 13
R21 B32 11
un
R21 B32 1 Miguel hola
RED 1
© Fco. Javier Yágüez García
hola
un
IP
Destino
saludo
un
TCP
B32 1 Miguel hola
un
IP
B32
B32 13 saludo
Destino
RED de Acceso
R22
R21
“P”
servidor
13 saludo
B32 11
R32
saludo
1 Miguel hola
ok!
R
(RECEPTOR)
Miguel
B
11
B32 1 Miguel hola
Destino
saludo
(CABECERA)
Protocolo
de Transporte TCP
B32 13 saludo
B32 11
un
Usuario
de Destino
Miguel
1 Miguel hola
Destino
DATOS DE USUARIO
DATOS DE USUARIO
saludo
Usuario
de Destino
“P”
cliente
CABECERA
APLICACIÓN
B22 B32 1 Miguel hola
B22 B32 11
un
RED de Acceso
B22
B22 B32 13 saludo
RED 2
ARQUITECTURA Y SERVICIOS DE INTERNET
9
Protocolo TCP (Transmission Control Protocol): Servicios

TRANSFERENCIAS DE FLUJO DE OCTETOS (BYTE-STREAM): Entidad TCP
emisora recoge, numera, almacena y agrupa los octetos de datos o carga útil (recibidos del
proceso de aplicación) en segmentos, calculando el MSS (Maximum Segment Size) para que
los datagramas IP se correspondan con la MTU de la red de acceso
 ORIENTADO A LA CONEXIÓN (conexión pareja de sockets)
 Control de errores (Fiabilidad):
 Lógicos (octetos de datos perdidos, desordenados y duplicados): temporizadores
(campo de datos de cada segmento de información tiene asociado un temporizador y
al vencimiento sin confirmación se produce una retransmisión), números de
secuencia (octeto de datos =número de secuencia), confirmaciones (campo de datos
de cada segmento de información tiene asociado una confirmación)
 Físicos (detección: suma de comprobación y corrección: temporizadores y
retransmisión)


 Control de flujo: Mecanismo de ventana deslizante ejercido por el receptor sobre
el emisor para evitar que éste desborde el buffer del receptor
MULTIPLEXADO o simultáneo a través de los números de puerto
TRANSFERENCIAS SIMÚLTÁNEAS EN LOS DOS SENTIDOS (full-dúplex)
 CONTROL DE LA CONGESTIÓN (en Internet): Mecanismo de ventana
ejercido por el emisor sobre sí mismo para evitar agravar una CONGESTIÓN
en INTERNET o seguir desbordando el buffer de recepción IP de un router
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
10
Tres Tipos de Ventanas en TCP
 Diferenciar las ventanas del control de flujo
TCP y la ventana del control de la congestión
TCP
 Toda entidad TCP dispone de una WT
(ventana de transmisión), WR (ventana de
recepción) y de una WC (ventana de
congestión)
Toda entidad TCP emisora dispone de una
WT (ventana de transmisión) y de una WC
(ventana de congestión)
Toda entidad TCP receptora dispone de
una WR (ventana de recepción)
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
11
El Control de Flujo y la Ventana de Recepción
RECORDATORIO
 El control de flujo lo ejerce la entidad TCP receptora a través
de su WR para evitar que la entidad TCP emisora desborde el
buffer de dicha entidad TCP receptora
 WR garantiza que no se inunde al receptor, ejerciendo un
control de flujo sobre el emisor
 WR controla la numeración de los octetos de datos que puede
enviar, en un momento dado, el emisor en función del
número de octetos libres que, en un momento dado, se pueden
almacenar en el buffer de recepción de la entidad TCP
receptora
 WR se corresponde con una lista de números de secuencia de
octetos de datos que, en un momento dado, el receptor puede
aceptar y almacenar en su buffer de recepción
 WT va variando puntualmente en fase de transferencia de
datos en función de la WR del otro extremo
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
12





El Control de la Congestión y la Ventana de Congestión
El control de la congestión lo ejerce la entidad TCP emisora
sobre sí misma a través de su WC para evitar que dicha
entidad TCP emisora siga desbordando el buffer de una
entidad intermedia IP en un router de Internet
El control de congestión permite que la entidad TCP emisora
baje el ritmo de transmisión cuando ocurre un desbordamiento
en el buffer de un router
WC garantiza que no se siga inundando a un router,
ejerciendo un control de transmisión en el emisor
WC indica el número de segmentos que puede enviar, en un
momento dado, en función de la congestión en Internet y se
calcula mediante un mecanismo o ALGORITMO
ADAPTATIVO a partir de una retransmisión (por “timeout”
o pérdida de un segmento de datos y/o confirmación)
WC actúa simultáneamente y en paralelo a WR
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
13
La Transferencia de Datos y la Ventana de Transmisión
 WT controla la numeración de los octetos de datos (enviados y no
confirmados) almacenados en el buffer de transmisión
 WT se corresponde con una lista de números de secuencia de
octetos de datos que, en un momento dado, el emisor ha enviado sin
haber recibido confirmación
 A medida que van llegando las confirmaciones, se DESACTIVAN los
temporizadores asociados y se va LIBERANDO espacio en el buffer de
transmisión para dejar sitio a nuevas copias de otros octetos de datos que se desean
transmitir
 El tamaño de WT viene determinado por la capacidad del
receptor y la capacidad de la red
 Espacio disponible en el buffer de recepción de la entidad TCP receptora
 Espacio disponible en los buffers de recepción IP de los routers intermedios entre el
origen y el destino
 WT = min (WR , WC )
 En cada momento, el emisor tomará en consideración la más pequeña de
las dos ventanas para asegurarse de que no desborda al receptor ni
provoca, o contribuye a agravar, una situación de congestión en la red
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
14
VENTANA DE RECEPCIÓN: Control de Flujo sin Congestión en la Red
Mientras no haya un congestión en la red, se lleva a cabo un control de flujo ejercido por WR
Control de flujo: Mecanismo de ventana deslizante ejercido por el receptor sobre el emisor
A
B
Aplicación
Aplicación
TCP
TCP
Envío
Recepción
Envío
Recepción
Buffer
Buffer
Buffer
Buffer
de Transmisión
de Recepción
de Transmisión
de Recepción
(Ventana de Transmisión)
(Ventana de Recepción)
(Ventana de Transmisión)
(Ventana de Recepción)
IP
IP
Control de los números
Ventana deslizante de recepción:
del buffer
BUFFER DE RECEPCIÓN
Números de secuencia de los octetos de
datos que en un momento
Nº SEC = n
Nº SEC = n+1 Nº SEC = n+2
Octetos de datos procedentes
dado el receptor puede aceptar y almacenar
de la entidad TCP emisora
se recogen,y almacenan
en el buffer de recepción
Primer octeto
Segundo octeto
Tercer octeto
...
Cuando se llena el buffer, se entregan al proceso de aplicación
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
15
VENTANA DE TRANSMISIÓN: Control de Flujo Sin Congestión en la Red
Mientras no haya un congestión en la red, la WT se ajusta en función de WR
A
B
Aplicación
Aplicación
TCP
TCP
Envío
Recepción
Envío
Recepción
Buffer
Buffer
Buffer
Buffer
de Transmisión
de Recepción
de Transmisión
de Recepción
(Ventana de Transmisión)
(Ventana de Recepción)
(Ventana de Transmisión)
(Ventana de Recepción)
IP
IP
Control de los números
del buffer
BUFFER DE TRANSMISIÓN
Octetos de datos procedentes
del proceso de aplicación
se recogen, numeran,
almacenan y agrupan
en el buffer de transmisión
Nº SEC = n
Primer octeto
Nº SEC = n+1 Nº SEC = n+2
Segundo octeto
Tercer octeto
Ventana deslizante de transmisión:
Números de secuencia de los octetos de
datos que en un momento
dado el emisor ha enviado sin haber
recibido confirmación
...
Cuando se llena el buffer, se van tomando trozos agrupándolos por segmentos y añadiéndoles una cabecera
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
16
PROTOCOLO TCP
Formato de un Segmento TCP
MSS = MTU - cabecera IP - cabecera TCP
CABECERA
DATOS (Variable)
20 octetos
sin opciones
Maximum Segment Size (MSS) = Carga Útil =
Se calcula un MSS de tal forma
= SDU del Nivel de Aplicación = 1024 octetos (típico MSS)
que los datagramas IP
resultantes se correspondan
con la MTU de la red de acceso
BUFFER DE TRANSMISIÓN
Octetos de datos procedentes
del proceso de aplicación
se recogen, numeran,
y almacenan
en el buffer de transmisión
Nº SEC = n
Primer octeto
Nº SEC = n+1 Nº SEC = n+2
Segundo octeto
Tercer octeto
...
Cuando se llena el buffer, se van tomando trozos agrupándolos por segmentos y añadiéndoles una cabecera
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
17
UN EJEMPLO SENCILLO DE VENTANA DESLIZANTE DE
TRANSMISIÓN Y RECEPCIÓN (2 octetos) SIN CONTROL
DE LA CONGESTIÓN (WT depende sólo de WR)
INICIALMENTE
232-1 0
1
2 octetos
DESPUÉS DE
ENVIAR 2 OCTETOS
232-1 0
1
DESPUÉS DE
ENVIAR 2 OCTETOS
SIN RECIBIR ACK
232-1 0
1
DESPUÉS DE
RECIBIR ACK
232-1 0
1
2
WT =
Límite inferior de WT=
= primer octeto de datos
INICIALMENTE
232-1 0
1
2 octetos
WR =
Se guarda copia
en el buffer de transmisión
de los dos octetos (0 y 1)
Nuevo límite inferior
al girar WT
DESPUÉS DE RECIBIR 2 OCTETOS
DESPUÉS DE
RECIBIR 2 OCTETOS Y PASARLOS AL NIVEL DE APLICACIÓN
232-1 0
232-1 0
232-1 0
1
1
1
2
2
3
3
Se reserva espacio
Se guarda copia
Se gira WR para los próximos
en el buffer de recepción en el buffer de recepción
2 nuevos octetos (2 y 3)
para los octetos 0 y 1 de los dos octetos (0 y 1)
ARQUITECTURA Y SERVICIOS DE INTERNET
© Fco. Javier Yágüez García
18
Sincronización de WR y WT para un Correcto Control de Flujo
 WR inicial = Tamaño máximo del propio buffer de recepción
 Posteriormente, en fase de transferencia de datos, WR va variando puntualmente en
función de los octetos libres de su buffer de recepción
 Se pasan datos al proceso de aplicación cuando se llena el buffer de
recepción
 Salvo que el bit PSH (Push) =1
 Se gira WR (límites inferior y superior) cuando se pasan datos
al proceso de aplicación (al llenarse el buffer de recepción)
 Límite inferior de WR = Primer octeto de datos que se espera recibir después
del último octeto pasado al proceso de aplicación
 WT inicial = WR inicial del otro extremo (tamaño máximo del buffer de
recepción del otro extremo)
 WT va variando, WT ≤ WR , en fase de transferencia de datos en función
de la WR del otro extremo
 Se gira WT (límites inferior y superior) cuando se recibe confirmación de
todos los octetos comprendidos entre el límite inferior y superior de WT
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
19
Formato de un Segmento TCP
Primer octeto
del campo de datos
del segmento de información
que se va a enviar = Nº de secuencia = 32 bits =
Módulo 232 = 0, 1, 2, …232-1, 0, 1, …, 232-1, 0, 1…
15 16
0
PUERTO ORIGEN
TCP
Máxima=60 octetos
PUERTO DESTINO
NÚMERO DE CONFIRMACIÓN (ACK)
Mínima por
=20 octetos
31
NÚMERO DE SECUENCIA
CABECERA
Omisión
Primer octeto
del campo de datos
del siguiente segmento
de información
que se espera recibir
(LOS OCTETOS ANTERIORES
ESTÁN CONFIRMADOS)
DESP
VENTANA
RESERVADO URG ACK PSH RST SYN FIN
SUMA DE COMPROBACIÓN
PUNTERO DATOS URGENTES
OPCIONES
RELLENO
DATOS (Variable)
SYN=1 ACK=0 Solicitud conexión
SYN=1 ACK=1 Respuesta OK!
Ventana deslizante de recepción:
Cantidad de octetos libres
Nº de octetos de datos
que se pueden almacenar
que el emisor de esta
información puede manejar en función del en el buffer de recepción
tamaño puntual de su buffer de recepción =
= 0 octetos, 1 octeto, 2 octetos hasta 216-1 octetos (65535 octetos o 16 unos)
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
20
PSEUDOCABECERA TCP
0
15 16
8
31
DIRECCIÓN IP ORIGEN
PSEUDOCABECERA
TCP
DIRECCIÓN IP DESTINO
00000000 PROTOCOLO = 6
LONGITUD DEL SEGMENTO TCP
CABECERA TCP
DATOS (Variable)
•La pseudocabecera se antepone a la cabecera TCP (al igual que en UDP),
pero sólo a efectos de calcular el checksum, no se envía realmente
•Para no violar la jerarquía de cabeceras de protocolos puesto que las
direcciones IP que contiene pertenecen al nivel IP
•Permite a la entidad TCP (al igual que a la entidad UDP) receptora detectar
segmentos TCP mal entregados, es decir, comprobar que su nivel IP no se
ha equivocado y le ha pasado un segmento TCP que era para otra máquina
aunque dicho segmento TCP esté libre de errores
•El valor 6 (110 en binario) indica que el protocolo de transporte es TCP
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
21
Formato de las Opciones TCP
Campos de Información de Control de Longitud Variable para
Servicios Adicionales
RFC-793 y RFC-1323
Formato TLV: Tipo-Longitud-Valor (o Datos)
TIPO
LONGITUD
8 bits
8 bits
DATOS…OPCIÓN
(variable)
Longitud completa
de la opción en octetos
(TIPO + LONGITUD + DATOS)
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
22
Opciones TCP más Relevantes
Descripción
TIPO
LONGITUD
(octetos)
DATOS
Descripción
0
-
-
Fin de la Lista
de Opciones
1
-
-
Sin operación
2
4
Valor MSS
MSS
3
3
Tamaño de la
Ventana
Escala de la
Ventana
4
2
-
SACK
PERMITTED
(Fase de
establecimiento)
5
Variable
-
SACK
(Fase de transferencia
de datos)
© Fco. Javier Yágüez García
8
10
Valor actual reloj emisor
(4 octetos) +
Respuesta Eco (4 octetos)
Marca de
Tiempo
…
…
…
…
ARQUITECTURA Y SERVICIOS DE INTERNET
23
Fase de Establecimiento de una Conexión TCP
Intercambio de 3 segmentos (con opción MSS)
Aparte de indicar el tamaño máximo de WR ,permite negociar opciones y números de
secuencia iniciales empleados en ambos extremos de la comunicación. Dichos números no
se reutilizarán durante un tiempo prudencial para evitar que los octetos de datos de
segmentos de información retrasados de una conexión se confundan con los de otra nueva
TCP “A”
Se confirman los números de
secuencia, las WR y las
opciones deseadas (p.ej., MSS)
© Fco. Javier Yágüez García
TCP “B”
ARQUITECTURA Y SERVICIOS DE INTERNET
Fase de Establecimiento de una Conexión TCP
Intercambio de 3 segmentos
Con VENTANA en “A” de 300 octetos y en “B” de 900 octetos
TCP “A”
Tamaño máximo
de VENTANA DE RECEPCIÓN
que desea “A”
Nº de secuencia que
desea usar la entidad “A”
TCP “B”
Ventana inicial:
• Control de flujo
impuesto por el
receptor
• La determina el
receptor al
establecer la
conexión
Tamaño máximo
de VENTANA DE RECEPCIÓN
que desea “B”
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
Ejemplo de Transferencia de Datos sin Errores
Transmisión unidireccional de datos (de “A” a “B”) sin errores
y con VENTANA en “A” de 300 octetos y en “B” de 900 octetos
TCP “A”
TCP “B”
…
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
Ejemplo de Transferencia de Datos con Errores
Transmisión unidireccional de datos (de “A” a “B”) con errores
(pérdidas de paquetes) y con VENTANA en “A” de 300 octetos y en “B” de 900 octetos
TCP “A”
TCP “B”
“A” transmite 900 octetos agrupados en 3
segmentos pendientes de confirmación
”B” ante la llegada de
los 300 primeros
octetos procede a
confirmarlos
No produce una retransmisión
(retransmisión por “timeout”)
sino una desactivación del timer
y una eliminación en el buffer de
transmisión de la copia de los
300 primeros octetos
Por omisión, mientras no
se reciba el segmento
perdido, se sigue
indicando, repetidamente
mediante
CONFIRMACIONES
DUPLICADAS, que se está
a la espera de sus octetos
de datos, ante la llegada
correcta de cualquier otro
segmento de datos no
contiguo o sin errores
CONFIRMACIÓN DUPLICADA Ante
la llegada correcta de bloques no
contiguos de octetos = NO
PRODUCE NINGÚN EFECTO en el
emisor de desactivación de timer y
eliminación de la copia de octetos
porque se ha hecho antes
time-out
No produce una retransmisión
retransmisión=timeout) sino una
desactivación de los timers y una
eliminación en el buffer de transmisión
de la copia de los 300 octetos del
segundo y tercer segmento
“B” vuelve a confirmar
los 300 primeros octetos
(no CONF=903 porque se
confirmarían los octetos
del 2º segmento)
time-out
DETECCIÓN DE DUPLICACIÓN
No producen ningún efecto
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
CAMPO DE OPCIONES DE INFORMACIÓN DE CONTROL
(LONGITUD VARIABLE DE HASTA 40 OCTETOS)






Se van incorporando poco a poco en las diferentes implementaciones de TCP
SE ESPECIFICAN EN LA FASE DE ESTABLECIMIENTO DE LA CONEXIÓN (sólo en aquellos segmentos
de control con el bit SYN = 1)
Tamaño Máximo de Segmento (MSS): Nº de octetos de la carga útil (campo de datos) que el receptor
(emisor de esta información) desea recibir para un procesado más óptimo de dicha carga. No confundir MSS con
el tamaño del buffer de recepción
Factor de Escala de la Ventana:
 Permite ampliar el campo VENTANA
 Equivale a usar un máximo de ventana de 32 bits. Por omisión, el tamaño máximo de la ventana de recepción
es de 216-1 octetos (65.535 octetos). Se puede escalar hasta llegar a 232-1 octetos (4.294.967.295 octetos o un
poco más de 4,2GB)
Confirmación selectiva (SACK: Selective Acknowledgment): Permite informar al emisor de los octetos
de datos de segmentos de información no contiguos que han sido recibidos correctamente y EVITAR
VENCIMIENTOS DE TEMPORIZADORES y RETRANSMISIONES INNECESARIAS, Implícitamente, indica
qué octetos de datos se han perdido o no han llegado todavía (“agujeros en los datos”)
Marca o sello de tiempo (Timestamp):
Tipo =8
Longitud = 10
Valor actual del reloj emisor
Eco del valor actual del reloj emisor
 Permite al emisor configurar sus temporizadores mediante el cálculo del valor RTT (Round Trip Time):
Tiempo de ida y vuelta desde que se envía un segmento de información hasta que se recibe su ACK
• Establecimiento de la conexión: El emisor puede enviar esta opción con SYN = 1, ACK = 0 y puede
hacer uso de dicha opción en otros segmentos, siempre y cuando, haya recibido respuesta con:
SYN = 1, ACK = 1
 Valor actual del reloj del emisor = valor monótamente creciente
 El eco es válido si el bit ACK = 1 en la cabecera del segmento
 El receptor devuelve el mismo valor (eco) en el ACK del segmento
 Asimismo, protege de errores de duplicación del NÚMERO DE SECUENCIA en conexiones de alta velocidad y, por
tanto, permite reconocer octetos distintos con el mismo número de secuencia en la misma conexión cuando los
números de secuencia dan la vuelta (0, 1, 2, …, 232-1, 0, 1…) durante el tiempo de vida de dicha conexión
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
28
Gestión de temporizadores en TCP
 No es lo mismo que el destino esté ubicado en la misma Ethernet o WiFi que disperso
geográficamente por Internet
 La elección de valores adecuados es mucho más compleja en el nivel de transporte que
en el nivel de enlace
 Diferencias en capacidad y retardo de unas conexiones TCP a otras
 Oscilaciones debidas a la presencia de routers y situaciones de congestión que están
fuera de su control
 Aún en situaciones de control, los routers pueden tener largas colas de datagramas IP
que atender, los enlaces pueden ser de diferentes velocidades y retardos y la ruta
puede variar durante la conexión
 La elección de un valor adecuado tiene una consecuencia directa en el funcionamiento
eficiente de TCP y hace que una implementación TCP sea más eficiente que otra
 Si el temporizador es demasiado alto, el emisor esperará innecesariamente en
ciertos casos por ACKs que nunca llegarán
 Si el temporizador es demasiado bajo se producirán retransmisiones innecesarias de
segmentos que habían sido correctamente recibidos
 Manejar los temporizadores (timers o timeouts) es siempre complejo porque hay que
determinar “aproximadamente” el periodo de tiempo existente desde que se envía un
segmento de información o datos hasta que se recibe su ACK, es decir, el tiempo de ida y
vuelta (RTT: Round Trip Time)
 Por todo lo anterior, los valores del temporizador se establecen mediante ALGORITMOS
AUTOADAPTATIVOS que dinámicamente ajustan los valores al estado de la red, según
es percibido éste por la entidad de transporte emisora
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
Temporizadores: Valores de Timeout
Estándar de Facto en las Implementaciones TCP
 Algoritmo autoadaptativo de Karn
para el cálculo del RTT (Round Trip
Time)
 Se toma una muestra RTT de cada segmento de
información transmitido (opción Marca de Tiempo)
 Se obtiene un promedio de dichas muestras
 Se le añade un margen de seguridad
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
30
Problemática TCP con Segmentos de Información
Perdidos o con Errores de Transmisión
 Segmentos TCP perdidos (DATOS y/o ACKs): En redes cableadas (Ethernet,
líneas serie o anillos en fibra óptica) la mayoría de las pérdidas es por congestión
IP en los routers y, además, por errores de transmisión en un nivel de enlace
inalámbrico (CRC WiFi), o por TTL = 0, IPv4 (checksum) y TCP (checksum)
 Errores físicos de transmisión: Redes inalámbricas no WiFi (Servicio no
orientado a conexión FIABLE), o redes de radio, enlaces móviles que
pueden provocar pérdidas de tramas a ráfagas
• Altas tasas de pérdidas de bits detectadas por SVT (pero sin
recuperación) y causadas por las pobres condiciones de propagación
 En los sistemas finales se aplica un control de flujo para evitar pérdidas de
datos extremo a extremo
 PROBLEMA: Mientras no se reciba correctamente el segmento de
información perdido (o que haya llegado con errores de transmisión), se envían
CONFIRMACIONES REPETIDAS y no se confirman los últimos segmentos
de información que han llegado correctamente PROVOCANDO EL
VENCIMIENTO DE SUS TEMPORIZADORES Y RETRANSMISIONES
INNECESARIAS
 SOLUCIÓN: Se introduce la opción de CONFIRMACIÓN SELECTIVA
(SACK: Selective Acknowledgment) que confirma los octetos de datos de
segmentos de información no contiguos que han sido recibidos correctamente
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
31
Tipos de Confirmaciones (ACKs)
 CONFIRMACIÓN (NO DUPLICADA O REPETIDA):
 Desactivación del temporizador del segmento de información que ha provocado dicha
confirmación
 Eliminación en el buffer de transmisión de la copia de los octetos de datos confirmados
 CONFIRMACIÓN DUPLICADA o REPETIDA:
 No produce ningún efecto si se ha hecho antes, es decir, no se ha perdido el anterior
ACK duplicado
 Peligro de que venza el temporizador del segmento de información no contiguo que ha
provocado dicha confirmación repetida Y SE REALICE UNA RETRANSMISIÓN
INNECESARIA
 Cuando al destino llegan segmentos TCP fuera de orden, el receptor transmite ACKs
duplicados o repetidos reconociendo que se han recibido segmentos no contiguos o fuera
de orden
 CONFIRMACIÓN DUPLICADA O REPETIDA CON SACK
(Selective Acknowledgment):
 DESACTIVACIÓN del temporizador del segmento de información no
contiguo
 ELIMINACIÓN en el buffer de transmisión de la copia de los octetos de
datos no contiguos confirmados
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
32
TCP SACK: TCP de Reconocimiento
Selectivo o Selective Acknowledgment
(SACK)
 Definido en el RFC-2018 y, posteriormente,
extendido en el RFC-2883
 Se recomienda la opción SACK cuando hay
múltiples pérdidas de segmentos TCP
 Por congestiones en los routers IP
 Por errores físicos en el nivel de enlace, especialmente, en
entornos inalámbricos (CRC de la trama)
 Para evitar innecesarias retransmisiones de
los octetos de datos de segmentos de
información no contiguos que ya fueron
entregados al receptor
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
33




Confirmación selectiva (SACK: Selective
Acknowledgment): RFC-2018 y RFC-2883
Dos Opciones
Para poder hacer uso de la opción Tipo 5 SACK en fase de
transferencia de datos hay que indicarlo previamente en fase de
establecimiento de la conexión TCP
Se indica mediante la opción Tipo 4 TCP Sack-Permitted en la fase
de establecimiento de la conexión TCP en un segmento SYN = 1
Mediante la opción Tipo 5 TCP Sack-Permitted se informa al
emisor de bloques no contiguos de octetos de datos que han sido
recibidos correctamente y, por tanto, en dónde puede haber
“agujeros en los datos”. Esta opción provoca la cancelación en el
emisor de los temporizadores de los segmentos que sabe que han
llegado correctamente al receptor y la eliminación de la copia de
los correspondientes octetos de datos en el buffer de transmisión
Si el receptor no ha recibido la opción Tipo 4 TCP SackPermitted en el establecimiento de la conexión, no debe usar la
opción Tipo 5 TCP Sack-Permitted en la fase de transferencia de
datos
ARQUITECTURA Y SERVICIOS DE INTERNET
© Fco. Javier Yágüez García
34
Un Ejemplo de un Paquete SACK
Transmisión unidireccional de datos (de “A” a “B”) con errores,
con VENTANA en “B” de 900 octetos,
y haciendo uso de la opción SACK
TCP “A”
TCP “B”
“A” transmite 900 octetos agrupados
en 3 segmentos pendientes de confirmación
“B” ante la llegada de los
300 primeros octetos
procede a confirmarlos
No produce una retransmisión
(retransmisión=timeout) sino una
desactivación del timer y una
eliminación en el buffer de
de transmisión de la copia de
los 300 primeros octetos
SEGMENTO CONTIGUO
(al último recibido correctamente)
SEGMENTO NO CONTIGUO
“B” emplea SACK
…
TCP “A” sabe que los octetos del
303 al 602 no han llegado todavía
pero sí los octetos del 603 al 902.
Por tanto cancela el temporizador
de dichos octetos (tercer segmento)
y elimina copia de los mismos
© Fco. Javier Yágüez García
PRIMER OCTETO DE DATOS RECIBIDO DEL
PRIMER SEGMENTO DE INFORMACIÓN NO
CONTIGUO QUE HA HECHO ENVIAR
EL PRIMER PAQUETE SACK
Permite confirmar al
emisor los octetos de
datos de SEGMENTOS DE
INFORMACIÓN NO
CONTIGUOS recibidos
correctamente o sin
errores, EVITANDO,
vencimiento de timers y
retransmisiones
innecesarias
PRIMER OCTETO DE DATOS QUE SE ESPERA
RECIBIR DEL SIGUIENTE SEGMENTO
DE INFORMACIÓN NO CONTIGUO
Y CONSECUTIVO
ARQUITECTURA Y SERVICIOS DE INTERNET
35
2 Tipos de Paquetes SACK
 Con 1 bloque de información de control en el
campo DATOS ÓPCIÓN
 Para segmentos de información NO CONTIGUOS Y
CONSECUTIVOS, es decir, SIN PÉRDIDAS entre ellos
 Con “n” bloques de información de control en
el campo DATOS ÓPCIÓN
 Para segmentos de información NO CONTIGUOS Y NO
CONSECUTIVOS, es decir, CON PÉRDIDAS entre ellos
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
36
Paquete SACK con “1 Bloque” para Segmentos
No Contiguos y Consecutivos (Sin Pérdidas)
USO DE LA OPCIÓN SACK CON CAMPO DATOS OPCIÓN DE UN ÚNICO BLOQUE
TIPO=5
LONGITUD
(variable)
DATOS OPCIÓN
X1 – Y1
 “X1” (32 bits) = BORDE IZQUIERDO DEL BLOQUE “1” = PRIMER NÚMERO DE
SECUENCIA DEL BLOQUE “1” = “PRIMER” OCTETO DE DATOS RECIBIDO DEL
“PRIMER” SEGMENTO DE INFORMACIÓN NO CONTIGUO QUE HA HECHO ENVIAR EL
“PRIMER” PAQUETE SACK
• X1 es el mismo valor para todos los paquetes SACK siempre que los siguientes segmentos de
información no contiguos recibidos sean consecutivos
 “Y1” (32 bits) = BORDE DERECHO DEL BLOQUE “1” = NÚMERO DE SECUENCIA
SIGUIENTE AL ÚLTIMO NÚMERO DE SECUENCIA DEL BLOQUE “1” = PRIMER
OCTETO DE DATOS QUE SE ESPERA RECIBIR DEL SIGUIENTE SEGMENTO DE
INFORMACIÓN NO CONTIGUO Y CONSECUTIVO
• Si los octetos de datos recibidos, de los siguientes segmentos de información no
contiguos, son consecutivos, entonces, se agrupan éstos en el mismo bloque X1-Y1
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
37
Un Ejemplo de un Paquete SACK con “1 Bloque”
Transmisión unidireccional de datos (de “A” a “B”) con errores
haciendo uso de SACK
CONFIRMACIONES A SEGMENTOS NO CONTIGUOS Y CONSECUTIVOS
(sin pérdidas) al último segmento de información recibido correctamente
TCP “A”
TCP “B”
¿Cuándo se retransmite el segmento
SEC=22550, Datos=431?
¿Respuestas de “B”?
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
38
TCP “A”
VENCIMIENTO
DEL
TEMPORIZADOR
(SOLUCIÓN)
TCP “B”
CONFIRMACIONES A BLOQUES
NO CONTIGUOS CONSECUTIVOS
Se intenta agrupar
el máximo de octetos
de datos consecutivos
en cada paquete SACK
Ante la llegada de
cualquier segmento,
de información no contiguo
y consecutivo, se indican
siempre los octetos de datos
ya recibidos y se agrupan
los octetos del último segmento
en el mismo bloque
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
39
Extensión con “N” Bloques del Paquete SACK para
Segmentos No Contiguos y No Consecutivos (Con Pérdidas)
TIPO=5
LONGITUD
(variable)
Informa del segmento recibido más recientemente
DATOS OPCIÓN
X1 – Y1 … Xn – Yn
 Se pueden enviar hasta 4 bloques NO CONSECUTIVOS SACK (34 octetos) si se emplea
casi todo el espacio del campo de opciones TCP (máximo de 40 octetos) para la opción
SACK
• Se recuerda que si los nuevos octetos de datos son consecutivos con los anteriores
ya recibidos, entonces, se agrupan en un mismo primer bloque X1-Y1
 El bloque 1 (X1 – Y1) debe informar del segmento recibido más recientemente. Asegura
que el ACK con la opción SACK refleje el cambio más reciente en el buffer de recepción.
Así el emisor tiene información actualizada del estado de la red y del estado de la cola de
recepción
• Si llega nuevos segmentos (p. ej., datos = 7000-7500 y 6000-6500) y se pueden
agrupar sus octetos con otro u otros bloques ya recibidos, entonces, se agrupan
todos los octetos que se puedan en el correspondiente bloque. P. ej.:
(6500-7000) (8000-8500) (7000-7500) (6000-6500) = (6000-7500) (8000-8500)
 Después del primer bloque SACK, los siguientes pueden estar listados en orden arbitrario
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
40
Extensión con “N” Bloques del Paquete SACK para
Segmentos No Contiguos y No Consecutivos (Con Pérdidas)
TIPO=5
LONGITUD
(variable)
Informa del segmento recibido más recientemente
DATOS OPCIÓN
X1 – Y1 … Xn – Yn
 “X1” (32 bits) = BORDE IZQUIERDO DEL BLOQUE “1” = PRIMER NÚMERO DE
SECUENCIA DEL BLOQUE “1” = PRIMER OCTETO DE DATOS RECIBIDO DEL SEGMENTO
DE INFORMACIÓN NO CONTIGUO QUE HA HECHO ENVIAR EL PAQUETE SACK
 “Y1” (32 bits) = BORDE DERECHO DEL BLOQUE “1” = NÚMERO DE SECUENCIA
SIGUIENTE AL ÚLTIMO NÚMERO DE SECUENCIA DEL BLOQUE “1” = PRIMER OCTETO
DE DATOS QUE SE ESPERA RECIBIR DEL SIGUIENTE SEGMENTO DE INFORMACIÓN NO
CONTIGUO Y CONSECUTIVO
• El bloque 1 (X1-Y1) debe informar del segmento recibido más recientemente.
• Después del primer bloque SACK, los siguientes pueden estar listados en orden arbitrario
 “Xn” (32 bits) = BORDE IZQUIERDO DEL BLOQUE “n” NO CONSECUTIVO = PRIMER
NÚMERO DE SECUENCIA DEL BLOQUE “n” = RECORDATORIO DEL PRIMER OCTETO DE
DATOS YA RECIBIDO DE UN SEGMENTO DE INFORMACIÓN NO CONTIGUO Y NO
CONSECUTIVO
 “Yn” (32 bits) = BORDE DERECHO DEL BLOQUE “n” NO CONSECUTIVO = NÚMERO DE
SECUENCIA SIGUIENTE AL ÚLTIMO NÚMERO DE SECUENCIA DEL BLOQUE “n” =
RECORDATORIO DEL PRIMER OCTETO DE DATOS QUE SE ESPERA RECIBIR DEL
SIGUIENTE SEGMENTO DE INFORMACIÓN NO CONTIGUO Y NO CONSECUTIVO
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
41
Un Ejemplo de un Paquete SACK Ampliado
Transmisión unidireccional de datos (de “A” a “B”) con errores
haciendo uso de SACK
CONFIRMACIONES A SEGMENTOS NO CONTIGUOS Y NO CONSECUTIVOS
TCP “A”
TCP “B”
¿Cuándo se retransmite el segmento
SEC=22550, Datos=431?
¿Respuestas de “B”?
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
42
TCP “A”
VENCIMIENTO
DEL
TEMPORIZADOR
(SOLUCIÓN)
TCP “B”
CONFIRMACIONES A BLOQUES
NO CONTIGUOS
NO CONSECUTIVOS
SACK ampliado
con más bloques
de información
Si hay espacio en el campo
de opciones TCP, se pueden
enviar hasta 4 bloques
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
43
C1
TCP “A”
ENTIDAD EMISORA
C2
TCP “B”
ENTIDAD RECEPTORA
Internet
Asumiendo que la entidad emisora TCP “A” de C1 transmite una ráfaga de
8 segmentos de información conteniendo cada uno 500 octetos de datos;
indicar la fase de transferencia de datos desde su inicio, por ejemplo,
mediante una tabla asociando los octetos de datos de los segmentos
de información y sus confirmaciones (Nº de Secuencia del primer octeto enviado,
ACK de respuesta, Datos SACK de respuesta)
Para ello, se debe tener en cuenta que:
La entidad receptora TCP “B” de C2 hace uso de la opción SACK y, además,
dispone en todo momento de suficiente capacidad en su buffer de recepción
El primer octeto de datos que espera recibir la entidad receptora TCP “B”
de C2 es el 5000
El primer segmento de información se pierde pero los 7 restantes se reciben
Las confirmaciones llegan a C1 en el momento adecuado
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
44
SEGMENTO ENVIADO
(SEC)
Nº DE CONFIRMACIÓN
(ACK)
DATOS OPCIÓN SACK
(BLOQUE SACK)
1
5000
(datos=500)
2
5500
(datos=500)
5000
5500-6000
3
6000
(datos=500)
5000
5500-6500
4
6500
(datos=500)
5000
5500-7000
5
7000
(datos=500)
5000
5500-7500
6
7500
(datos=500)
5000
5500-8000
7
8000
(datos=500)
5000
5500-8500
8
8500
(datos=500)
5000
5500-9000
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
45
C1
TCP “A”
ENTIDAD EMISORA
C2
TCP “B”
ENTIDAD RECEPTORA
Internet
Asumiendo que la entidad emisora TCP “A” de C1 transmite una ráfaga de
8 segmentos de información conteniendo cada uno 500 octetos de datos
(y sin tener en cuenta el envío del ejemplo anterior); indicar la fase de
transferencia de datosdesde su inicio, por ejemplo, mediante una tabla
asociando los octetos de datos de los segmentos de información y sus
confirmaciones (Nº de Secuencia del primer octeto enviado, ACK de respuesta,
Datos SACK de respuesta)
Para ello, se admite que:
La entidad receptora TCP “B” de C2 hace uso de la opción SACK y, además,
dispone en todo momento de suficiente capacidad en su buffer de recepción
El primer octeto de datos que espera recibir la entidad receptora TCP “B” de C2
es el 5000
Se pierden los segmentos segundo, cuarto, sexto y octavo pero los restantes
se reciben
Después de transmitirse el octavo segmento, se retransmiten por vencimiento de
temporizadores y, por tanto, se reciben fuera de orden el cuarto y, a continuación,
el segundo segmento de información
Las confirmaciones llegan a C1 en el momento adecuado
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
46
SEGMENTO
ENVIADO
(SEC)
Nº DE CONFIRMACIÓN
(ACK)
1
5000
(datos=500)
5500
2
5500
(datos=500)
3
6000
(datos=500)
4
6500
(datos=500)
5
7000
(datos=500)
6
7500
(datos=500)
7
8000
(datos=500)
8
8500
(datos=500)
4
2
DATOS OPCIÓN
SACK
DATOS OPCIÓN
SACK
DATOS OPCIÓN
SACK
(PRIMER BLOQUE
SACK)
(SEGUNDO BLOQUE
SACK)
(TERCER BLOQUE
SACK)
5500
6000-6500
5500
7000-7500
6000-6500
5500
8000-8500
7000-7500
6500
(datos=500)
5500
6000-7500
8000-8500
5500
(datos=500)
7500
© Fco. Javier Yágüez García
6000-6500
(agrupa)
8000-8500
(agrupa)
ARQUITECTURA Y SERVICIOS DE INTERNET
47
Congestión en Internet
RFC-5681: TCP Congestión Control
 Congestión = Pérdida de 1 o más paquetes o datagramas IP
 Causa posible: Desborde del buffer de la cola del interfaz de salida
de un ROUTER
 Exceso de tráfico de entrada en alguna o algunas redes de Internet: Tasas de
paquetes de entrada superan las capacidades de los enlaces salida
• La situación se complica si los enlaces de salida son de menor
capacidad que los enlaces de entrada
 En principio, no se puede conocer el estado de todos los sistemas intermedios
 Cuando los paquetes llegan a la parte congestionada de la red, como el
router de acceso no puede aceptar todo el tráfico entrante,
empezará a acumularlos en su buffer de la cola del interfaz de
salida y cuando éste se llene, empezará a descartar
 Basta que uno de los enlaces del trayecto se vea afectado por la congestión para
limitar el tráfico en todo el camino y, por tanto, el rendimiento de la
comunicación entre los sistemas finales
 Las aplicaciones se bloquean o dejan de funcionar
 La congestión se detecta en TCP por vencimiento de temporizadores o
“timeouts” (alta probabilidad de congestión)
 La entidad TCP receptora recibirá sólo una parte de los segmentos por lo que la entidad
TCP emisora retransmitirá por timeout aquéllos que no hayan sido confirmados
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
48
Pérdidas de Paquetes en los Routers
La congestión en Internet es la pérdida de 1 o más paquetes IP
debido al desborde del buffer de la cola del interfaz de salida
de un router cuando las tasas de entrada superan las capacidades de salida
enlaces
de entrada
…
Proceso
IP
Caudal
IP
IP
IP
IP
buffer de la cola
del interfaz de salida
enlaces
de entrada
…
enlace
de salida
Descarte del último
CONGESTIONES O PERDIDAS DE PAQUETES IP EN UN ROUTER DE ACCESO,
ESPECIALMENTE CRÍTICO EN ENLACES DE ENTRADA DE ALTA CAPACIDAD
Y ENLACES DE SALIDA DE MENOR CAPACIDAD
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
49
Flujo y Congestión: Conceptos Diferentes
RECORDATORIO
 La VENTANA DE RECEPCIÓN WR garantiza que no se inunde
al receptor ejerciendo un CONTROL DE FLUJO sobre el emisor
 Sin embargo, los problemas podrían estar en Internet: Muchas
veces el “cuello de botella” está en la red y no en el receptor
 Los buffers de las colas de salida de los routers pueden desbordarse
 Además, del CONTROL DE FLUJO necesitamos un CONTROL
DE CONGESTIÓN
 ¿Cómo notificar a la entidad TCP emisora de que hay una saturación en algún
punto del trayecto y de que debe bajar el ritmo de transmisión?
Mediante una VENTANA DE CONGESTIÓN WC
que indica el número de segmentos que el emisor puede
enviar en un momento dado sin congestionar a ningún
router en Internet
 La WC actúa simultáneamente y en paralelo con WR
 Respuesta:
 En cada momento, el emisor tomará en consideración la más pequeña de
las dos ventanas para asegurarse de que no satura al receptor ni provoca,
o contribuye a agravar, una situación de congestión en la red
WT = min (WR , WC )
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
50
Flujo y Congestión: Conceptos Diferentes
 La WR se notifica al emisor por el receptor: EL
CONTROL DE FLUJO LO EJERCE LA ENTIDAD
TCP RECEPTORA
 La WC la calcula el emisor a partir de la cantidad de
retransmisiones (pérdidas de segmentos TCP o
“timeouts”) que tiene que realizar: EL CONTROL DE
LA CONGESTIÓN LO EJERCE LA ENTIDAD TCP
EMISORA
 El emisor va tanteando la red, transmitiendo tan rápido
como sea posible hasta que se produzca un “timeout”, a
partir de ahí reduce, drásticamente, el ritmo de sus envíos
(WC y, por tanto WT) y va aumentando dicho ritmo,
paulatinamente, hasta un nuevo “timeout” (nueva pérdida y
retransmisión), repitiendo de nuevo el proceso
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
51
Mecanismos de Control de la Congestión
RFC-5681
Implemetados en cualquier distribución actual TCP/IP
y utilizados por el protocolo TCP cuando los routers en Internet descartan o
pierden paquetes IP al desbordarse la capacidad de almacenamiento de los buffers
asociados a las colas de los interfaces de salida
1. Comienzo Lento (Slow Start)
2. Prevención de la Congestion (Congestion
Avoidance)
3. Retransmisión Rápida (Fast Retransmit)
4. Recuperación Rápida (Fast Recovery)
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
52
Mecanismo de Control de la Congestión
Comienzo Lento o SS (Slow Start)
 Con SS se transmiten segmentos de información de forma exponencial
(1, 2, 4, 8, ...) al ritmo al que se reciben los ACK desde el otro extremo
 WC , que SE MIDE EN SEGMENTOS con un campo datos, por omisión, de
1024 octetos (1 segmento = 1 MSS, por omisión, de 1Kbyte o 1024 octetos),
crece exponencialmente sólo si todos los segmentos de información enviados
han sido confirmados
• Si hay un ACK retrasado, el incremento, en el tamaño de WC, no es
exponencial
 Se denomina COMIENZO LENTO porque se empieza a transmitir
lentamente, primero 1 segmento, luego 2 segmentos y, así, sucesivamente;
pero en realidad se transmite muy rápido (exponencialmente): 1, 2, 4, 8, 16,
32, 64) y en sólo 7 interacciones (envío de un grupo de 64 segmentos de
información) se llega a 65.535 octetos (asumiendo un MSS típico de 1024
octetos) que es el valor máximo por omisión de TCP para WR y que coincide
con el VALOR INICIAL DEL UMBRAL DE CONGESTIÓN o UMBRAL
DE PELIGRO o LÍMITE DE CRECIMIENTO DE WC impuesto por TCP,
el cual va variando posteriormente en función de la congestión en Internet
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
53
Inicio de la Fase de Transferencia de Datos con
Comienzo Lento o SS (Slow Start): Sin Congestión en la Red
Con SS se envían segmentos de información
a la red de forma exponencial (1, 2, 4, 8, etc.)
al ritmo al que se reciben los ACK desde el otro extremo
TCP “A”
WC = 1
TCP “B”
ACK
WC = 2
Cada ráfaga confirmada ACKs
duplica WC
WC = 4
ACKs
…
© Fco. Javier Yágüez García
Si hay un ACK retrasado
el incremento en el
tamaño de la ventana es
menor que la potencia de 2
ARQUITECTURA Y SERVICIOS DE INTERNET
54
Comienzo Lento o SS (Slow Start) Sin Congestión en la Red
1ª interacción
WC SE MIDE EN SEGMENTOS con 1 MSS,
por omisión, de 1Kbyte o 1024 octetos. Por
tanto, 1 segmento = 1024 octetos
WC se inicializa a 1 segmento o 1 MSS de
1 Kbyte (1024 octetos)
A su vez, p.ej., WR = 65.535 octetos
Todos los segmentos tienen
un MSS por omisión = 1024 octetos = 1Kbyte
y se activa el primer timer.
WT = min (WR =65.535 octetos, WC = 1)
Si ACK llega antes del timeout
WT = WC = 2 Kbytes y se envían
2 segmentos y se activan 2 timers.
Si llegan los ACK a tiempo
WT = WC = 4 Kbytes y se envían
4 segmentos y se activan 4 timers.
WC va creciendo
EXPONENCIALMENTE
duplicándose en cada envío.
Sin congestión, WC crece
rápidamente y en sólo 7 interacciones
(1, 2, 4, 8, 16, 32, 64) se llegaría a 65.535 octetos
(valor máximo de TCP para WR)
© Fco. Javier Yágüez García
2ª interacción
3ª interacción
4ª interacción
…
ARQUITECTURA Y SERVICIOS DE INTERNET
55
Mecanismo de Control de la Congestión
Comienzo Lento o SS (Slow Start)
1. WC = 1 (inicialmente 1 segmento o 1 MSS del tamaño máximo para la conexión)
2.
Valor inicial del umbral de congestión = 64 segmentos o 65.535 octetos (valor
máximo de WR )
3. WC = 1, 2, 4, 8, …, (WT = WC) va creciendo exponencialmente
(mientras se reciben todos los ACK) hasta superar:
 La WR actual y puntual en el otro extremo TCP (se establece un control de flujo)
 El valor inicial del umbral de congestión o umbral de peligro o límite de crecimiento
máximo impuesto por TCP inicialmente para WR de 65.535 octetos
 El buffer de algún router y se produzca la primera pérdida de paquete o “timeout”
4. Cada vez que se detecta un “timeout” o pérdida se obtiene un nuevo
UMBRAL DE CONGESTIÓN, que toma como valor la mitad del tamaño
actual de WC . A su vez, WC se reduce de una manera drástica al valor
inicial de 1 segmento. Ahora, WC empieza a crecer exponencialmente como
antes (WC = 1, 2, 4, 8, …, ) pero sólo hasta el nuevo umbral de congestión
donde permanece aunque no haya pérdidas
 Nuevo umbral de congestión o límite de crecimiento de WC = WC (actual)/2
 WC = 1 (y, luego, 2, 4, 8, …)


Reducción rápida y significativa del tráfico para que el router se recupere
Mientras el tamaño máximo de WC permanezca en el umbral de congestión, no
se enviará una ráfaga de mayor longitud, sin importar la cantidad de espacio
de WR ofrecida por el receptor en el supuesto de ser superior
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
56
Mecanismo de Control de la Congestión
Prevención de la Congestion o CA (Congestion Avoidance)
 Para aumentar el rendimiento en la transferencia, se combina SS y CA con el
objetivo de seguir transmitiendo a partir de donde SS finaliza, es decir, desde el
nuevo umbral de congestión calculado en SS
 Para ello, se incrementa WC LINEALMENTE (de “1 en 1”) desde el nuevo
umbral hasta que se supere el tamaño actual de WR en el otro extremo TCP
(control de flujo) o el buffer de algún router (vencimiento de temporizador),
REPITIÉNDOSE EL PROCESO
 Una nueva pérdida (congestión), momento a partir del cual se aplica de
nuevo SS, obteniéndose un nuevo umbral de congestión, en un valor
igual a la mitad del tamaño actual de WC. A su vez, WC se reduce de una
manera drástica al valor inicial de 1 segmento. Ahora, WC de nuevo
empieza a crecer exponencialmente, pero sólo hasta el nuevo umbral de
congestión a partir del cual se vuelve a aplicar CA
 El objetivo es no quedarse bloqueado en el nuevo umbral (SS) sino seguir
transmitiendo lentamente desde dicho nuevo umbral dando tiempo a que el
router se recupere
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
57
Prevención de la Congestión (Congestion
Avoidance) y Comienzo Lento (Slow Start)
Funcionamiento conjunto
 Objetivo de cada algoritmo:
Comienzo Lento o SS (Slow Start): Tantear la red,
transmitiendo, tan rápido como sea posible, hasta que se
produce una congestión, momento a partir del cual se calcula
el nuevo umbral, se reduce WC = 1 y se transmite
exponencialmente hasta el nuevo umbral
Prevención de la Congestión o CA (Congestion
Avoidance) = Una vez que se ha producido la congestión, y
en combinación con SS, sigue transmitiendo linealmente a
partir de donde SS finaliza (nuevo umbral de congestión),
dando tiempo a que el router se recupere
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
58
Ejemplo de Funcionamiento Conjunto de SS y CA: Se producen
perdidas de segmentos de información cuando WC es mayor de
20 segmentos o 20 Kbytes (1 segmento = 1 MSS de 1 Kbyte)
FASE
UMBRAL DE
CONGESTIÓN en
KBytes
WC en KBytes
(VENTANA DE
CONGESTIÓN)
64 segmentos
Primera
(valor inicial)
Segunda
Tercera
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
59
Ejemplo de Funcionamiento Conjunto de SS y CA: Se producen
perdidas de segmentos de información cuando WC es mayor de
20 segmentos o 20 Kbytes (1 segmento = 1 MSS de 1 Kbyte)
FASE
UMBRAL DE
CONGESTIÓN en
KBytes
WC en KBytes
(VENTANA DE
CONGESTIÓN)
SS
Primera
64 (valor inicial)
1,2,4,8,16,32
Se produce un timeout cuando WC = 32
A partir del umbral =16, WC se incrementa de 1 en 1
Segunda
16
1,2,4,8,16,17,18,19,20,21
SS
CA
A partir del umbral =10,5, WC se incrementa de 1 en 1
Tercera
10,5
Umbral de congestión = 10 porque si
se envían 11 segmentos > 10,5
© Fco. Javier Yágüez García
1,2,4,8,10,11,12,13,14,15,
16,17,18,19,20,21
ARQUITECTURA Y SERVICIOS DE INTERNET
60
2 Tipos de Retransmisiones TCP
 En las implementaciones actuales TCP, hay una
RETRANSMISIÓN si:
Expira un temporizador de retransmisión
= PÉRDIDA SEGURA DE SEGMENTO =
Alta seguridad de que haya congestión en
Internet
Llegan 3 CONFIRMACIONES (ACKs)
duplicadas = PÉRDIDA PROBABLE DE
SEGMENTO = No hay seguridad de que haya
congestión en Internet “PERO, POR SI
ACASO”, no se espera al vencimiento del
temporizador y se aplica el mecanismo de
Retransmisión Rápida
ARQUITECTURA Y SERVICIOS DE INTERNET
© Fco. Javier Yágüez García
61
2 Tipos de Control de la Congestión
 Si la detección se debe a un vencimiento de temporizador =
ALTA SEGURIDAD DE CONGESTIÓN y se aplica SS y CA
 CONTROL DE LA CONGESTIÓN (Comienzo Lento y
Prevención de la Congestión) A PARTIR DE UN
“TIMEOUT”
 Si la detección de debe a 3 ACKs duplicados = BAJA
SEGURIDAD DE CONGESTIÓN y, en principio, se aplica
RETRANSMISIÓN RÁPIDA
 CONTROL DE LA CONGESTIÓN (Prevención de la
Congestión) A PARTIR DE 3 ACKs DUPLICADOS que
implica como ventaja adicional una recuperación más
rápida del potencial segmento de información perdido sin
esperar a que expire su temporizador
 Puede ser que a lo mejor no se ha perdido el segmento, es
decir, no hay congestión y no es necesario que WC = 1
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
62
Mecanismo de Control de la Congestión:
Retransmisión Rápida (Fast Retransmit)
 Retransmisión de un
segmento después de
la recepción de 3
ACKs duplicados,
sin esperar al
“timeout”
 3 ACKs duplicados
significa que,
probablemente, se ha
perdido 1 segmento
Si se han recibido 3 ACKs
hay una probabilidad baja
de congestión, se puede
haber perdido un segmento
pero 3 segmentos ya han llegado
ya que se han recibido 3 ACKs
3 ACKs duplicados
= 4 ACKs idénticos en secuencia
RETRANSMISIÓN
Por si acaso, no se espera a que se “dispare”
el temporizador de retransmisión de “b”
Si se reciben 3 ACKs duplicados
seguidos, retransmitir de inmediato
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
63
Retransmisión Rápida
 No es un mecanismo estricto de control de la
congestión en Internet
 Es un mecanismo de retransmisión de la
forma más rápida posible (sin esperar el
vencimiento del temporizador) de un
segmento de información y que, posiblemente
(no es seguro), se ha perdido debido a una
presumible congestión en un router por la
llegada de 3 confirmaciones duplicadas
 Pero en combinación, a su vez, con el
mecanismo de Prevención de la Congestión
(CA) da origen a un nuevo mecanismo de
control de la congestión denominado
Recuperación Rápida (Fast Recovery)
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
64
Mecanismo de Control de la Congestión:
Recuperación Rápida (Fast Recovery)
 Si la probable congestión se debe a 3 ACKs
DUPLICADOS = Se hace una Recuperación
Rápida = Retransmisión rápida y CA (a partir del
nuevo umbral)
• Se retransmite inmediatamente el segmento afectado
(RETRANSMISIÓN RÁPIDA), se calcula el nuevo umbral de
congestión y se comienza DIRECTAMENTE en una nueva
fase de CA a partir del nuevo umbral (sin comenzar desde 1
segmento a crecer exponencialmente hasta el nuevo umbral y,
luego, linealmente)
• P. ej., si se han recibido 3 ACKs, se calcula el nuevo umbral =
6, se retransmite inmediatamente el segmento afectado y se
comienza linealmente a partir de 7, 8, 9, … (y no a partir de 1,
2, 4, 6, 7, 8, 9, …, etc., porque tal vez no hay congestión y no es
necesario que WC = 1)
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
65
Ejemplo de Recuperación Rápida: Se produce “timeout” cuando
WC = 20 segmentos y el nuevo umbral de congestión = 16 segmentos.
Posteriormente, se reciben 3 ACKs cuando se envían 12 segmentos
WC máxima en
FASE
UMBRAL DE
CONGESTIÓN
En un momento anterior, WC =32, se
produjo timeout y el nuevo umbral de
congestión pasó a valer 16
Primera
16
segmentos
(VENTANA DE
CONGESTIÓN) =32
SS
CA…
1, 2, 4, 8, 16, 17, 18,
19, 20 (timeout)
CA…
SS
Segunda
10
1, 2, 4, 8, 10, 11, 12
(3 ACKs)
CA …
Tercera
© Fco. Javier Yágüez García
6
7, 8, 9, …, 20 (timeout)
ARQUITECTURA Y SERVICIOS DE INTERNET
66
Implementaciones TCP
 RFC-793, STD 0007 (1981):
 TCP Sin control de congestión
 RFC-5681 (1999):
 TCP con control de la congestión
 Implementación TCP Tahoe (1988)
 Algoritmo básico de control de congestión (Comienzo lento)
 Implementación TCP Reno (1990)
 Tahoe + Prevención de la congestión + Retransmisión rápida + Recuperación
rápida
 Implementación TCP New Reno (1996)
 El Reno optimizado es la implementación, por omisón, que
se encuentra en la mayoría de las distribuciones TCP/IP e
incluye los cuatro mecanismos de control de la congestión
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
67
2 Notificaciones de Congestion en TCP
 Notificación o señalización implícita por:
– Vencimiento de temporizador (“timeout”)
» Mecanismos: SS y CA
– Recepción de 3 ACKs duplicados
» Mecanismos: Recuperación rápida = Retransmisión rápida y
CA (a partir del nuevo umbral)
 Notificación o señalización explícita por indicación del router
• ECN (Explicit Congestion Notification): RFC-3168 y RFC-2884
• La transmisión se ajusta en la entidad TCP emisora sólo cuando una
entidad IP intermedia, que empieza a acercarse a su umbral de
congestión, se lo notifica explícitamente a la entidad TCP receptora y
ésta se lo comunica, finalmente, a la entidad TCP emisora
– VENTAJA: En vez de descartar, y que se produzcan timeouts, el
router señaliza al receptor antes de que los buffers se llenen
– Despúes, el receptor avisa al emisor y éste disminuye el ritmo de
envío
• Ya hay algunas implementaciones de ECN (Linux)
• Alternativa de señalización explícita: Mensaje ICMPv4 de frenado en el origen
(Tipo=4 Código=0): No se usa por seguridad (prevención de ataque a un
router). Además, no existe el mensaje ICMPv6 de frenado en el origen
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
68
DATAGRAMA IPv4
Recordatorio
Los 2 bits de menor orden del campo ToS de la cabecera
IPv4 se usan para la notificación explícita de congestión
4
4
VERSIÓN
8
Longitud
Cabecera
16
TIPO DE SERVICIO
0
IDENTIFICADOR
TIEMPO DE VIDA
(TTL)
LONGITUD TOTAL
000 R C F 00
D M
F F
DESPLAZAMIENTO
SUMA DE COMPROBACIÓN
(CABECERA)
PROTOCOLO
CABECERA
DIRECCIÓN ORIGEN
DIRECCIÓN DESTINO
RELLENO
OPCIONES
DATOS
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
69
Cabecera IPv4:DSCP-ECN
Punto de Código de Servicios Diferenciados
Differentiated Services
Code Point
4
4
VERSIÓN
8
Longitud
Cabecera
TIPO DE SERVICIO
DSCP
TIEMPO DE VIDA
(TTL)
ECT (Explicit Congestion Notification) Capable Transport =
Bit de Transporte de Notificación Explícita de Congestión
EC (Experienced Congestion) = Bit de Detección de Congestión
16
E
C E
T C
LONGITUD TOTAL
0
IDENTIFICADOR
Para control de la congestión
D M
F F
PROTOCOLO
DESPLAZAMIENTO
SUMA DE COMPROBACIÓN
(CABECERA)
CABECERA
DIRECCIÓN ORIGEN
DIRECCIÓN DESTINO
RELLENO
OPCIONES
DATOS
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
70
Cabecera Fija IPv6:DSCP-ECN
Punto de Código
de Servicios Diferenciados
Differentiated Services
Code Point
0
4
Versión
Prioridad (8bits)
12
ECT/EC
31
Etiqueta de flujo (20 bits)
xxxxxxxx
Longitud de la carga útil
Cabecera
siguiente
Dirección de origen (16 octetos)
Límite
de saltos
40
octetos
Dirección de destino (16 octetos)
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
71
Formato de un Segmento TCP-ECN
(Explicit Congestion Notification)
Los 2 bits de menor orden del campo RESERVADO de la
cabecera TCP se usan para el control de la congestión
15 16
0
PUERTO ORIGEN
31
PUERTO DESTINO
NÚMERO DE SECUENCIA
NÚMERO DE CONFIRMACIÓN (ACK)
RESERVADO
4 BITS
DESP
C
W
R
E
C
N
VENTANA
URG ACK PSH RST SYN FIN
SUMA DE COMPROBACIÓN
PUNTERO URGENTE
RELLENO
OPCIONES
DATOS (Variable)
Explicit Congestion Notification-Echo =
= Bit de Eco de Notificación Explícita de Congestión
Congestion Window Reduced =
= Bit de Ventana de Congestión Reducida
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
72
Cabecera TCP-ECN
 El uso de ECN en fase de transferencia de datos obliga
a indicarlo previamente en fase de establecimiento de la
conexión TCP
 El EMISOR activa los 2 bits (CWR y ECN-ECHO) en
el segmento de solicitud de establecimiento de la
conexión y el RECEPTOR activa el bit ECN-ECHO en
el segmento de respuesta SYN =1, ACK =0
 SYN = 1, ACK = 0 (SOLICITUD con los bits CWR = 1 y ECN-ECHO = 1)
 SYN = 1, ACK = 1 (RESPUESTA con los bits CWR = 0 y ECN-ECHO = 1)
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
73
Control de la Congestion en TCP
 Metodología por Señalización Explícita ECN
Notification Congestion): RFC-3168 y RFC-2884
(Explicit
El emisor activa el bit de Transporte de Notificación Explícita de
Congestión o ECT (ECN Capable Transport) de la cabecera IP
solicitando bit de Eco de Notificación Explícita de Congestión
(ECN) para dicho paquete a cualquier router que detecte congestión
El router, al empezar a acercarse a su umbral de congestión, activa
el bit EC=1, activa el bit de Detección de Congestión o EC
(Experienced Congestion) de la cabecera IP y lo encamina a la
entidad TCP receptora
La entidad receptora TCP, al recibir dicha cabecera IP, detecta que
hay principio de congestión en el camino y activa el bit de Eco de
Notificación Explícita de Congestión (ECN-ECHO) de la cabecera
TCP y se lo envía a la entidad TCP emisora para que ésta active el
control de la congestión
La entidad emisora TCP, al recibir ECN-ECHO = 1, activa el bit de
Ventana de Congestión Reducida o CWR (Congestion Window
Reduced) de la cabecera TCP y se lo envía a la entidad TCP
receptora para indicar que ya se enterado, que ya ha activado el
control de congestión, que ya ha reducido su ritmo de transmisión y
que no es necesario que le vuelva a enviar un ECN-ECHO = 1
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
74
Esquema IP-ECN/TCP-ECN
Bit de Transporte de
Notificación Explícita de Congestión
Transmisor
ECT
1
IP
Bit de
Detección de Congestión
Router (cercano a la congestión)
ECT EC
EC
0
1
1
1
TCP
0
0
CWR
CWR
2
Receptor
1
TCP
ECN-ECHO
TCP
3
1
CWR
Bit de Ventana de
de Congestión Reducida
© Fco. Javier Yágüez García
4
Bit de Eco de
Notificación Explícita de Congestión
ARQUITECTURA Y SERVICIOS DE INTERNET
75
Problemática de la Fiabilidad TCP
 Hay aplicaciones que no toleran el retardo extremo a extremo
producido por los ACKs, los temporizadores, las
retransmisiones y controles de TCP
 Además, el control de congestión TCP reduce la tase de envío
(throughput) en el emisor
 Las retransmisiones TCP son inaceptables para aplicaciones
interactivas en tiempo real (p. ej., videoconferencias y VoIP) y
no interactivas (streaming de audio y vídeo), al incrementar el
retardo extremo a extremo
 Cada vez hay más aplicaciones sobre UDP
 Tráfico interactivo en tiempo real
• Audioconferencias, vídeoconferencias, VoIP
 Tráfico no interactivo en tiempo real
• Streaming de audio y vídeo
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
76
Protocolo UDP (User Datagram Protocol)
RFC-768, STD 0006
 Se utiliza en los siguientes escenarios:
Aplicaciones interactivas (audioconferencias,
videoconferencias, VoIP, etc.) y no interactivas
(streaming de audio y vídeo, etc.) en tiempo
real
 El intercambio de mensajes es muy escaso y los
mensajes son cortos, por ejemplo, consultas al DNS
 Los mensajes se producen regularmente y no importa
si se pierde alguno: SNMP, NTP, …
 Los mensajes se envían en una RAL del tipo Ethernet
(sin errores físicos): DHCP, SNMP, …
 Para tráfico broadcast/multicast
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
77
Protocolo UDP (User Datagram Protocol)
RFC-768, STD 0006
Transporte NO FIABLE PERO RÁPIDO
de los mensajes de aplicación encapsulados en datagramas UDP
SIN CONTROLES
SISTEMA FINAL
EXTREMO A EXTREMO
mensajes
APLICACIÓN
SISTEMA FINAL
APLICACIÓN
SERVICIO NO ORIENTADO A CONEXIÓN NO
FIABLE PERO RÁPIDO
UDP
ROUTER
IP
IP
INTERFAZ DE
RED
INTERFAZ
DE RED
Ethernet
UDP
ROUTER
…
INTERFAZ
DE RED
INTERFAZ
DE RED
…
IP
IP
INTERFAZ
DE RED
INTERFAZ DE
RED
PPP
Las unidades de datos del protocolo UDP (“PDUs UDP”)
se denominan datagramas UDP o mensajes UDP
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
78
Protocolo UDP (User Datagram Protocol)
RFC-768, STD 0006
 Protocolo muy sencillo que añade un mínimo de
sobrecarga
 Añade muy poco al servicio de IP como es
proporcionar comunicación proceso a proceso en lugar
de máquina a máquina
 SERVICIO NO ORIENTADO A CONEXIÓN NO
FIABLE
Con detección (opcional) y no recuperación de errores
físicos
Sin control (detección y recuperación) de errores lógicos
(datagramas UDP perdidos y desordenados)
Sin control de errores, flujo y congestión
 Multiplexación/Demultiplexación
 Transferencias simúltáneas en los dos sentidos (fulldúplex)
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
79
PROTOCOLO UDP
Formato de un Datagrama UDP
RFC-768, STD 0006
Longitud Total Máxima
65.535 octetos
CABECERA
DATOS
8 octetos
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
80
Formato de un Datagrama UDP
15 16
0
CABECERA
UDP
(8 octetos)
PUERTO ORIGEN
LONGITUD UDP
31
PUERTO DESTINO
SUMA DE COMPROBACIÓN
DATOS
Longitud en octetos del datagrama UDP
(cabecera + datos) =
Longitud mínima de 8 octetos (sin datos),
Longitud máxima de 65.535 octetos (pero la longitud
total debe ser menor debido a que un paquete IP tiene
una longitud máxima de 65.535 octetos)
© Fco. Javier Yágüez García
A todo el datagrama UDP
(cabecera y datos)
Uso opcional:
Si entidad UDP emisora
pone “todo a ceros” = No usar
ARQUITECTURA Y SERVICIOS DE INTERNET
81
PSEUDOCABECERA UDP
0
8
15 16
31
DIRECCIÓN IP ORIGEN
PSEUDOCABECERA
DIRECCIÓN IP DESTINO
UDP
00000000
PROTOCOLO = 17 LONGITUD DEL DATAGRAMA UDP
CABECERA UDP
DATOS (Variable)
•La pseudocabecera se antepone a la cabecera UDP (al igual que en TCP),
pero sólo a efectos de calcular el checksum, no se envía realmente
•Para no violar la jerarquía de cabeceras de protocolos puesto que las
direcciones IP que contiene pertenecen al nivel IP
•Permite a la entidad UDP (al igual que a la entidad TCP) receptora detectar
datagramas UDP mal entregados, es decir, comprobar que su nivel IP no se
ha equivocado y le ha pasado un datagrama UDP que era para otra máquina
aunque dicho datagrama UDP esté libre de errores
•El valor 17 (10001 en binario) indica que el protocolo de transporte es UDP
© Fco. Javier Yágüez García
ARQUITECTURA Y SERVICIOS DE INTERNET
82