Network Working Group M

Las Request For Comments —petición de comentarios— son una serie de notas sobre Internet
que comenzaron a publicarse en 1969. Se abrevian como RFC.
Cada una de ellas individualmente es un documento cuyo contenido es una propuesta oficial para
un nuevo protocolo de la red Internet (originalmente de ARPANET), que se explica con todo
detalle para que en caso de ser aceptado pueda ser implementado sin ambigüedades.
Cualquiera puede enviar una propuesta de RFC a la IETF, pero es ésta la que decide finalmente
si el documento se convierte en una RFC o no. Si luego resulta lo suficientemente interesante,
puede llegar a convertirse en un estándar de Internet.
Cada RFC tiene un título y un número asignado, que no puede repetirse ni eliminarse aunque el
documento se quede obsoleto.
Cada protocolo de los que hoy existen en Internet tiene asociado un RFC que lo define, y
posiblemente otros RFC adicionales que lo amplían. Por ejemplo el protocolo IP se detalla en el
RFC 791, el FTP en el RFC 959, y el HTTP (escrito por Tim Berners-Lee, entre otros) el RFC
2616.
Existen varias categorías, pudiendo ser informativos (cuando se trata simplemente de valorar por
ejemplo la implantación de un protocolo), propuestas de estándares nuevos, o históricos (cuando
quedan obsoletos por versiones más modernas del protocolo que describen).
Las RFC se redactan en inglés según una estructura específica y en formato de texto ASCII.
Antes de que un documento tenga la consideración de RFC, debe seguir un proceso muy estricto
para asegurar su calidad y coherencia. Cuando lo consigue, prácticamente ya es un protocolo
formal al que probablemente se interpondrán pocas objeciones, por lo que el sentido de su
nombre como petición de comentarios ha quedado prácticamente obsoleto, dado que las críticas
y sugerencias se producen en las fases anteriores. De todos modos, el nombre de RFC se
mantiene por razones históricas.
Network Working Group M. Mathis

Petición de Comentarios: 2018 J. Mahdavi
Categoría: Informativo PSC
S. Floyd
LBNL
A. Romanow
Sun Microsystems
Octubre 1996
Opciones de notificación de recepción selectiva en TCP
Estado de este memorándum
Este documento proporciona información para la comunidad Internet.

No es la especificación de ningún estándar de Internet. La
distribución de este memorándum no está limitada.
Nota de Copyright
Copyright (C) The Internet Society (1996). Todos los derechos

reservados.
Resumen
El protocolo TCP puede experimentar un bajo rendimiento cuando se

pierden múltiples paquetes de datos de una ventana. Con la limitada
información que se dispone de las notificaciones de recepción
acumulativas, un remitente TCP solo puede enterarse de un único
paquete perdido por cada viaje de ida y vuelta. Un remitente
agresivo podría optar por retransmitir paquetes más pronto, pero
dichos segmentos retransmitidos podrían haber sido recibidos ya
correctamente.
Un mecanismo de notificación de recepción selectivo (SACK), combinado

con una política selectiva de repetición de retransmisiones, puede
ayudar a salvar dichas limitaciones. El receptor TCP devuelve
paquetes SACK al remitente informándole de los datos que han sido
recibidos. El remitente puede por tanto retransmitir solo los
segmentos de datos que falta.
Este memorándum propone una implementación de SACK y discute su

rendimiento y aspectos relacionados.
Reconocimientos
Gran parte del texto de este documento se ha tomado directamente del

RFC1072 [16] «Extensiones TCP para rutas con retardos grandes» por
Bob Braden y Van Jacobson. A los autores les gustaría agradecer a
Mathis, et al. Informativo [Pág. 1]
RFC 2018 Notificación de recepción selectiva Octubre 1996
Kevin Fall (LBNL), Christian Huitema (INRIA), Van Jacobson (LBNL),

Greg Miller (MITRE), Greg Minshall (Ipsilon), Lixia Zhang (XEROX PARC
y UCLA), Dave Borman (BSDI), Allison Mankin (ISI) y otros sus
revisiones y comentarios constructivos.
Indice
1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. La opción SACK-Permitted . . . . . . . . . . . . . . . . . . . 5
3. Formato de la opción SACK . . . . . . . . . . . . . . . . . . 6
4. Generando opciones SACK: Comportamiento del receptor de
datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Interpretando la opción SACK y la estrategia de
retransmisión: Comportamiento del remitente de datos . . . . . 10
5.1 Aspectos sobre el control de congestiones . . . . . . . . . . 10
6. Eficiencia y comportamiento del peor caso . . . . . . . . . . 12
7. Ejemplos de opciones SACK . . . . . . . . . . . . . . . . . . 13
8. Renuncia por parte del receptor de los datos . . . . . . . . . 15
9. Consideraciones de seguridad . . . . . . . . . . . . . . . . . 16
Referencias . . . . . . . . . . . . . . . . . . . . . . . . . 17
Dirección de los autores . . . . . . . . . . . . . . . . . . . 18
A. Créditos de la traducción y conversión a XML . . . . . . . . . 19
Declaración completa de Copyright . . . . . . . . . . . . . . 20
1. Introducción
La pérdida de múltiples paquetes de una ventana de datos puede tener

efectos catastróficos en el rendimiento del protocolo TCP. TCP [12]
emplea un esquema de notificación de recepción en el cual, los
segmentos recibidos que no están en el borde izquierdo de la ventana
a la que pertenecen, no se notifican. Esto fuerza al remitente que o
bien espere que se agote el tiempo de espera de la notificación para
detectar los paquetes perdidos, o reenvíe segmentos que han sido
correctamente recibidos [3]. Con el esquema de la notificación de
recepción acumulativa, los múltiples segmentos descartados causan,
generalmente, que el protocolo TCP pierda su reloj basado en las
notificaciones (ACK), reduciendo el rendimiento global.
La notificación de recepción selectiva (SACK) es una estrategia que

corrige este comportamiento en el escenario de múltiples segmentos
descartados. Con la notificación de recepción selectiva, el receptor
de los datos puede informar al remitente de todos los segmentos que
han llegado correctamente, por lo que el remitente solo tiene que
retransmitir los segmentos que han sido perdidos.
Diversos protocolos de transporte, incluidos el NETBLT [2], XTP [14],

RDP [15], NADIR [5], y VMTP [1] utilizan notificación de recepción
selectiva. Hay algunas evidencias empíricas a favor de la
notificación de recepción selectiva -- experimentos simples con RDP
han mostrado que desactivando la prestación de la notificación de
recepción selectiva incrementa bastante el número de segmentos
retransmitidos en las rutas de Internet con alto retardo y con
grandes pérdidas de paquetes [11]. Un estudio de simulación reciente
hecho por Kevin Fall y Sally Floyd [3], demuestra la fuerza del
protocolo TCP con SACK sobre las implementaciones Tahoe y Reno del
protocolo TCP sin SACK.
El RFC1072 [VJ88] [17] describe una posible implementación de las

opciones SACK para TCP. Desafortunadamente, nunca se ha llegado a
desplegar en Internet, pues hubo desacuerdos sobre como las opciones
SACK debían ser utilizadas en conjunción con la opción del cambio de
ventana TCP (inicialmente descrito en el RFC1072 y revisado en [8]).
Nosotros proponemos unas ligeras modificaciones de las opciones SACK

tal y como se propusieron en el RFC1072. Específicamente, el envío
de una notificación de recepción selectiva para los datos recibidos
recientemente, reduce la necesidad de opciones SACK largas [9][10].
Además, la opción SACK ahora se compone de secuencias de números de
32 bit. Estas dos modificaciones representan los únicos cambios de
la propuesta en el RFC1072. Dichos cambios hacen SACK más fácil de
implementar y soluciona los problemas sobre su robustez.
Esta extensión de notificación de recepción selectiva emplea dos

opciones TCP. La primera es una opción de habilitación, «SACK-
permitted», la cual se puede enviar en un segmento SYN para indicar
que la opción SACK puede ser empleada una vez se ha establecido la
conexión. La otra es una opción propia de SACK que puede ser enviada
mediante una conexión establecida una vez se ha dado permiso mediante
SACK-permitted.
La opción SACK se incluye en un segmento enviado desde una conexión

TCP que está recibiendo datos de la conexión TCP que está enviando
dichos datos; nos referiremos a dichas conexiones TCP como el
receptor de datos y el remitente de datos respectivamente.
Consideraremos un flujo de datos simple en particular; cualquier
flujo de datos en la dirección inversa sobre la misma conexión puede
ser tratada independientemente.
2. La opción SACK-Permitted
Esta opción de dos bytes se puede enviar mediante un SYN por una
conexión TCP que ha sido extendida para recibir (y probablemente para
procesar) la opción SACK una vez que la conexión se ha abierto. NO
DEBE ser enviada en segmentos distintos del SYN.
La opción SACK-Permitted en TCP:
Tipo: 4
+---------+------------+
| Tipo=4 | Longitud=2 |
+---------+------------+
3. Formato de la opción SACK
La opción SACK se empleará para transportar información extendida

sobre la notificación de recepción desde el receptor al remitente
sobre una conexión TCP establecida.
Opción SACK en TCP:
Tipo: 5
Longitud: Variable
+--------+--------+
| Tipo=5 |Longitud|
+--------+--------+--------+--------+
| Borde izquierdo del primer bloque |
+--------+--------+--------+--------+
| Borde derecho del primer bloque |
+--------+--------+--------+--------+
| |
/ . . . /
| |
+--------+--------+--------+--------+
| Borde izquierdo del bloque n-esimo|
+--------+--------+--------+--------+
| Borde derecho del bloque n-esimo |
+--------+--------+--------+--------+
La opción SACK se enviará por un receptor de datos para informar al

remitente de los datos de los bloques de datos no continuos que se
han recibido y encolados. El receptor de datos espera la recepción
de datos (quizás mediante retransmisiones) para rellenar los huecos
de la secuencia vacía entre los bloques recibidos. Cuando se reciben
segmentos que faltaban, el receptor de datos notifica la recepción de
datos, generalmente, desplazando el borde izquierdo de la ventana en
el campo numérico de la notificación de recepción de la cabecera TCP.
La opción SACK no cambia el significado del campo número de
notificación de recepción.
Esta opción contiene una lista de algunos de los bloques de

secuencias continuas de datos que han sido recibidos y encolados
dentro de la ventana.
Cada bloque continuo de datos encolados en el receptor de datos está

definido en la opción SACK por dos enteros sin signo de 32 bits con
la ordenación de bytes de red:
o Borde izquierdo del primer bloque: Es el primer número de la
secuencia de este bloque.
o Borde derecho del primer bloque: Es el número de la secuencia que

sigue inmediatamente al último número de la secuencia de este
bloque.
Cada bloque representa los bytes de datos recibidos que están

contiguos y aislados; es decir, los bytes justo antes del bloque,
(Borde izquierdo del bloque - 1), y justo después del bloque, (Borde
derecho del bloque), no han sido recibidos.
Una opción SACK que especifica n bloques tendrá una longitud de 8*n+2
bytes, por tanto, los 40 bytes disponibles para las opciones TCP
pueden especificar un máximo de 4 bloques. Normalmente SACK se
empleará junto con la opción Timestamp empleada para RTTM [8], que
emplea 10 bytes adicionales (más dos bytes de alineación); por lo que
solo se podrán emplear 3 bloques SACK en este caso.
La opción SACK es solo informativa, por tanto, aunque notifique al

remitente de los datos que el receptor de datos ha recibido los
segmentos indicados, el receptor de los datos puede descartar
posteriormente los datos que se han notificado en una opción SACK.
En la sección 8 hay una discusión de las consecuencias de las
notificaciones SACK, en particular, que el receptor de datos puede
renunciar o descartar datos ya enviados por SACK.
4. Generando opciones SACK: Comportamiento del receptor de datos
Si el receptor de datos ha recibido la opción SACK-Permitted en el

SYN de esta conexión, el receptor de datos puede optar por generar
opciones SACK como se describe a continuación. Si el receptor de
datos genera opciones SACK bajo alguna circunstancia, DEBE generarlas
bajo todas las circunstancias permitidas. Si el receptor de datos no
ha recibido una opción SACK-Permitted para una determinada conexión,
NO DEBE enviar opciones SACK por dicha conexión.
Si se envían, las opciones SACK DEBEN ser incluidas en todos los ACKs
que no notifiquen el número de secuencia más alto de la cola del
receptor de datos. Es esta situación, la red ha perdido o
desordenado datos, por tanto el receptor mantiene datos no continuos
en su cola. En el RFC1122, Sección 4.2.2.21, se discute los motivos
por los que un receptor enviará ACKs en respuesta a segmentos
adicionales recibidos en este estado. El receptor DEBE enviar un ACK
por cada segmento válido que llegue conteniendo nuevos datos, y cada
uno de esos ACKs «duplicados» DEBEN llevar una opción SACK.
Si el receptor de datos escoge enviar una opción SACK, se aplican las

siguientes reglas:
o El primero bloque SACK (es decir, el que sigue inmediatamente a

los campos tipo y longitud en la opción) DEBE especificar el
bloque de datos continuo que contiene el segmento que lanzo este
ACK, a no ser que dicho segmento incremente el campo numérico de
notificación de recepción de la cabecera. Esto asegura que el ACK
con la opción SACK refleja el cambio más reciente en el buffer de
la cola del receptor de datos.
o El receptor de datos DEBE incluir en la opción SACK, tantos

bloques SACK distintos como le sea posible. Tenga presente que el
espacio máximo disponible para las opciones puede que no sea
suficiente para informar de todos los bloques presentes en la cola
del receptor.
o La opción SACK DEBE ser rellenada repitiendo los bloques SACK que
fueron notificados recientemente (basados en el primer bloque SACK
de las opciones SACK anteriores) que no son un subconjunto de
alguno de los otros bloques SACK ya incluidos en la opción SACK
que se está construyendo. Esto asegura que en una operación
normal, cualquier parte del segmento que quede de un bloque no
continuo de datos almacenado por el receptor se notificará en al
menos tres opciones SACK sucesivas, incluso para implementaciones
TCP con ventanas muy grandes [RFC1323] [18]. Después del primer
bloque SACK, los siguientes bloques SACK de la opción SACK pueden
estar listados en orden arbitrario.
Es muy importante que la opción SACK siempre informe el bloque que

contiene el segmento que se ha recibido más recientemente, pues esto
facilita al remitente la información más actualizada sobre el estado
de la red y de la cola del receptor de datos.
5. Interpretando la opción SACK y la estrategia de retransmisión:

Comportamiento del remitente de datos
Cuando un ACK recibido contiene una opción SACK, el remitente de los

datos DEBE registrar la notificación de recepción selectiva para su
uso posterior. Se asume que el remitente de los datos tiene una cola
de retransmisión que contiene los segmentos que han sido transmitidos
pero que no se ha notificado su recepción, en ordenados por su número
de secuencia. Si el remitente de los datos vuelve a empaquetar
dichos datos antes de la retransmisión, los límites del bloque de una
opción SACK que reciba puede que no coincidan con los límites de los
segmentos de la cola de retransmisión; sin embargo, esto no supone
una dificultad seria para el remitente.
Una posible implementación del comportamiento del remitente es la

siguiente. Supongamos que por cada segmento de la cola de
retransmisión hay un (nuevo) bit de estado «SACKed», que se empleará
para indicar que ese segmento en particular ha sido mencionado en una
opción SACK.
Cuando se recibe un segmento de confirmación de recepción con una

opción SACK, el remitente de los datos activará los bits SACKed de
los segmentos que han sido notificados selectivamente. En concreto,
por cada bloque de la opción SACK, el remitente de los datos activará
los bits SACKed de todos los segmentos de la cola de retransmisión
que están completamente contenidos dentro de cada bloque. Esto
requiere de comparaciones directas de los números de secuencia.
Después que el bit SACKed se activa (como resultado de procesar una

opción SACK recibida), el remitente de los datos saltará dicho
segmento durante cualquier retransmisión posterior. Cualquier
segmento que tiene el bit SACKed desactivado y sea inferior al
segmento más grande con el bit SACKed activado, está disponible para
ser retransmitido.
Después de agotarse el tiempo de espera de una retransmisión el

remitente de los datos DEBE desactivar todos los bits SACKed, ya que
al agotarse el tiempo de espera, puede significar que el receptor de
los datos ha renunciado. El remitente de los datos DEBE retransmitir
el segmento del borde izquierdo de la ventana después de agotarse el
tiempo de espera de una retransmisión, esté activado o no el bit
SACKed de dicho segmento. Un segmento no se eliminará de la cola ni
se liberará su buffer hasta que el borde izquierdo de la ventana lo
sobrepase.
5.1 Aspectos sobre el control de congestiones
Este documento no pretende especificar en detalle los algoritmos de
control de congestión para la implementación del protocolo TCP con

SACK. Sin embargo, los algoritmos de control de congestión presentes
en las implementaciones del estándar de facto TCP DEBEN ser
preservados [13]. En particular, para mantener la robustez frente a
paquetes reordenados por la red, la recuperación no se dispara por un
solo informe ACK fuera-de-orden en el receptor. Es más, durante la
recuperación el remitente de datos limita el número de segmentos
enviados en respuesta a cada ACK. Las implementaciones existentes
limitan al remitente de los datos a enviar un segmento durante las
recuperaciones rápidas del tipo Reno, o dos segmentos durante el
inicio-lento (slow-start) [6]. Otros aspectos del control de
congestiones, como es la reducción de la ventana congestionada en
respuesta a una congestión, debe ser preservados de forma similar.
El uso de tiempos de espera como un mecanismo de detección de

paquetes descartados no varían con la opción SACK. Ya que el
receptor de los datos puede descartar datos SACKed, cuando se agota
el tiempo de espera de una retransmisión el remitente de los datos
DEBE ignorar la información SACK anterior para determinar que datos
debe retransmitir.
Investigaciones futuras sobre algoritmos de control de congestión

pueden sacar provecho de la información adicional que provee SACK.
Una posible área de estudio de este tipo es la modificación del
protocolo TCP para entornos inalámbricos o por satélite donde la
pérdida de paquetes no es necesariamente una indicación de
congestión.
6. Eficiencia y comportamiento del peor caso
Si la ruta de retorno que lleva los ACKs y las opciones SACK no

tuviese ninguna pérdida, sería siempre suficiente un bloque por cada
paquete con opciones SACK. Cada segmento que llegase mientras el
receptor de datos mantiene datos discontinuos causará que el receptor
de datos envíe de vuelta un ACK con una opción SACK conteniendo el
bloque alterado de la cola del receptor. El remitente de los datos
puede por tanto construir una réplica precisa de la cola del receptor
uniendo todos los primeros bloques SACK.
Dado que la ruta de retorno siempre perderá paquetes, la opción SACK

se define para que incluya más de un bloque SACK en un solo paquete.
Los bloques redundantes en el paquete con las opciones SACK
incrementan la robustez de la entrega SACK frente a pérdidas de ACKs.
Para un receptor que también está empleando la opción Timestamp [8],
la opción SACK tiene espacio para incluir tres bloques SACK. Por
tanto, cada bloque SACK se repetirá al menos tres veces, si es
necesario, una vez en cada tres paquetes ACK sucesivos. Sin embargo,
si todos los paquetes ACK que informan de un bloque SACK en
particular se descarta, el remitente puede asumir que los datos en
dichos bloques SACK no han sido recibidos, y retransmita de forma
innecesaria dichos segmentos.
El uso de otras opciones TCP pueden reducir el número de bloques SACK

disponibles a 2 o incluso a 1. Esto reducirá la redundancia de la
entrega SACK frente a pérdidas de ACKs. Incluso así, la necesidad de
retransmisión innecesaria de paquetes de TCP con SACK es
estrictamente menor que la de las implementaciones actuales del
protocolo TCP. Las condiciones del peor caso necesarias para que el
remitente retransmita datos innecesarios se discute con más detalle
en un documento separado [4].
Las implementaciones anteriores de TCP que no tienen la opción SACK

no se verán perjudicadas negativamente cuando compitan con otras
implementaciones TCP con SACK. Este aspecto se discute con más
detalle en [4].
7. Ejemplos de opciones SACK
Los siguientes ejemplos intentan demostrar el correcto comportamiento

para la generación de opciones SACK por el receptor de datos.
Asumimos que el borde izquierdo de la ventana es 5000 y que el

transmisor de datos envía un grupo de 8 segmentos, cada uno contiene
500 bytes de datos.
Caso 1: Los primeros 4 segmentos se reciben pero los últimos 4 se

descartan.
El receptor de datos devolverá un segmento TCP de ACK normal

notificando la recepción con el número de secuencia 7000, sin
opciones SACK.
Caso 2: El primer segmento se descarta pero los restantes 7 se

reciben.
Con la recepción de cada uno de los últimos siete paquetes, el

receptor de datos devolverá un segmento TCP de ACK que notificará
la recepción con el número de secuencia 5000 y conteniendo una
opción SACK especificando un bloque de datos encolados:
Segmento
que se Borde Borde
envía ACK izquierdo derecho
5000 (perdido)
5500 5000 5500 6000
6000 5000 5500 6500
6500 5000 5500 7000
7000 5000 5500 7500
7500 5000 5500 8000
8000 5000 5500 8500
8500 5000 5500 9000
Caso 3: Los segmentos segundo, cuarto, sexto y octavo (último) se

descartan.
El receptor de datos envía ACKs del primer paquete de forma

normal. El tercero, quinto y séptimo paquete mandan opciones SACK
como las que siguen:
Segmento Primer bloque Segundo bloque Tercer

bloque
que se Borde Borde Borde Borde Borde
Borde
envía ACK izquierdo derecho izquierdo derecho izquierdo
derecho
5000 5500
5500 (perdido)
6000 5500 6000 6500
6500 (perdido)
7000 5500 7000 7500 6000 6500
7500 (perdido)
8000 5500 8000 8500 7000 7500 6000
6500
8500 (perdido)
Suponga en este punto, que el cuarto paquete se recibe fuera de

orden. (Esto puede deberse o bien porque los datos se
desordenaron en la red, o porque el segundo paquete fue
retransmitido y perdido, y luego el cuarto paquete se
retransmitió). En este momento el receptor de datos solo tiene
dos bloques SACK de los que informar. El receptor de datos
responde con la siguiente notificación de recepción selectiva:
Segmento Primer bloque Segundo bloque Tercer bloque

que se Borde Borde Borde Borde Borde Borde
derecho
6500 5500 6000 7500 8000 8500
Suponga que en este punto, se recibe el segundo segmento. El

receptor de datos por tanto responde con la siguiente notificación
de recepción selectiva:
Segmento Primer bloque Segundo bloque Tercer

bloque
que se Borde Borde Borde Borde Borde
Borde
derecho
5500 7500 8000 8500
8. Renuncia por parte del receptor de los datos
Tenga presente que el receptor de los datos puede descartar de su

cola datos que no han sido notificados al remitente, incluso si se ha
informado de dichos datos en una opción SACK. Dicho descarto de
paquetes SACKed no es recomendable, pero puede realizarse si el
receptor se queda sin espacio en el buffer de paquetes.
El receptor de datos PUEDE decidir no mantener datos que han sido

notificados en una opción SACK. En este caso, la generación de la
opción SACK por parte del receptor se realizará de esta forma:
o El primer bloque SACK DEBE reflejar el segmento más nuevo.

Incluso si el segmento más nuevo va a ser descartado y el receptor
ha descartado ya segmentos adyacentes, el primer bloque SACK DEBE
informar, como mínimo, los bordes izquierdo y derecho del segmento
más nuevo.
o Excepto para el segmento más nuevo, todos los bloques SACK NO

DEBEN informar de cualquier dato antiguo que ya no es almacenado
por el receptor.
Dado que el receptor de los datos puede descartar posteriormente

datos notificados en una opción SACK, el remitente NO DEBE descartar
datos antes de que sea notificada su recepción por el campo del
número de notificación de la cabecera TCP.
9. Consideraciones de seguridad
Este documento ni mejora ni empeora las características actuales de

seguridad del protocolo TCP.
Referencias
[1] Cheriton, D., "VMTP: Versatile Message Transaction Protocol",

RFC 1045, February 1988.
[2] Clark, D., Lambert, M. y L. Zhang, "NETBLT: A Bulk Data

Transfer Protocol", RFC 998, March 1987.
[3] Fall, K. y S. Floyd, "Comparisons of Tahoe, Reno, and Sack

TCP", December 1995.
[4] Floyd, S., "Issues of TCP with SACK", January 1996.
[5] Huitema, C. y I. Valet, "An Experiment on High Speed File

Transfer using Satellite Links", October 1981.
[6] Jacobson, V., "Congestion Avoidance and Control", August 1988.
[7] Jacobson, V. y R. Braden, "TCP Extensions for Long-Delay

Paths", RFC 1072, October 1988.
[8] Jacobson, V., Braden, R. y D. Borman, "TCP Extensions for High

Performance", RFC 1323, May 1992.
[9] "presentation to the Internet End-to-End Research Group",

November 1994.
[10] Mathis, M. y J. Mahdavi, "TCP Forward Acknowledgment Option,

presentation to the Internet End-to-End Research Group", June
1995.
[11] Partridge, C., "Private Communication", February 1987.
[12] Postel, J., "Transmission Control Protocol - DARPA Internet

Program Protocol Specification", RFC 793, September 1981.
[13] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols",

1994.
[14] Strayer, T., Dempsey, B. y A. Weaver, "XTP -- the xpress

transfer protocol", 1992.
[15] Velten, D., Hinden, R. y J. Sax, "Reliable Data Protocol", RFC

908, July 1984.
[16] <ftp://ftp.isi.edu/in-notes/rfc1072.txt>
[19] <http://xml.resource.org/public/rfc/html/rfc2629.html>
[20] <mailto:carlos@pemas.net>
Dirección de los Autores
Matt Mathis
Pittsburgh Supercomputing Center
4400 Fifth Ave
Pittsburgh, PA 15213
US
EMail: mathis@psc.edu
Jamshid Mahdavi
Pittsburgh Supercomputing Center
4400 Fifth Ave
Pittsburgh, PA 15213
US
EMail: mahdavi@psc.edu
Sally Floyd
Lawrence Berkeley National Laboratory
One Cyclotron Road
Berkeley, CA 94720
US
EMail: floyd@ee.lbl.gov
Allyn Romanow
Sun Microsystems, Inc.
2550 Garcia Ave.
MPK17-202
Mountain View, CA 94043
US
EMail: allyn@eng.sun.com
Apéndice A. Créditos de la traducción y conversión a XML
Este RFC ha sido traducido y convertido a XML según la especificación

del RFC2629 [19] por Carlos Perelló Marín [20] en mayo de 2003.
Declaración completa de Copyright
Copyright (C) The Internet Society (1996). Reservados todos los

derechos.
Le está permitido copiar y entregar a terceros este documento en su

versión original o traducida. Puede procesar, copiar, publicar y
distribuir, en parte o en totalidad, sin restricción de ningún tipo,
trabajos derivados que comenten, expliquen o ayuden en la
implementación de este documento, siempre que en cada copia o trabajo
derivado incluya la mención de Copyright anterior junto con la
presente nota. No le está sin embargo permitido modificar en ningún
modo este documento, eliminar la mención de Copyright ni las
referencias a The Internet Society u otras organizaciones de
Internet, excepto con el fin de desarrollar los estándares de
Internet (en cuyo caso deberá seguir los procedimientos para
copyrights definidos en el proceso de Estándares Internet), o con el
fin de traducirlo a otros idiomas distintos del inglés.
Los permisos limitados concedidos más arriba son perpétuos y no serán

revocados por la 'Internet Society' o sus sucesores o cesionarios.
Este documento y la información contenida se ofrece "TAL CUAL". THE

INTERNET SOCIETY Y THE INTERNET ENGINEERING TASK FORCE DESCARTAN
CUALQUIER GARANTÍA EXPRESA O IMPLICITA POR EL USO DE LA INFORMACIÓN
AQUÍ CONTENIDA Y EN PARTICULAR EXCLUYEN, SIN LIMITACIÓN ALGUNA, TODA
GARANTÍA SOBRE POSIBLES INFRACCIONES DE DERECHOS O GARANTÍAS
IMPLÍCITAS DE COMERCIALIZACIÓN Y ADECUACIÓN A LOS FINES PERSEGUIDOS.
Agradecimiento
Los fondos para las funciones desempeñadas por el editor RFC son
proporcionados actualmente por la Internet Society.

Network Working Group M

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Network Working Group M

Uploaded by

Copyright:

Available Formats

Las Request For Comments —petición de comentarios— son una serie de notas sobre Internet

que comenzaron a publicarse en 1969. Se abrevian como RFC.

Network Working Group M. Mathis

Opciones de notificación de recepción selectiva en TCP

Estado de este memorándum

Este documento proporciona información para la comunidad Internet.

Copyright (C) The Internet Society (1996). Todos los derechos

El protocolo TCP puede experimentar un bajo rendimiento cuando se

Un mecanismo de notificación de recepción selectivo (SACK), combinado

Este memorándum propone una implementación de SACK y discute su

Gran parte del texto de este documento se ha tomado directamente del

Mathis, et al. Informativo [Pág. 1]

RFC 2018 Notificación de recepción selectiva Octubre 1996

Kevin Fall (LBNL), Christian Huitema (INRIA), Van Jacobson (LBNL),

Mathis, et al. Informativo [Pág. 2]

RFC 2018 Notificación de recepción selectiva Octubre 1996

La pérdida de múltiples paquetes de una ventana de datos puede tener

La notificación de recepción selectiva (SACK) es una estrategia que

Diversos protocolos de transporte, incluidos el NETBLT [2], XTP [14],

El RFC1072 [VJ88] [17] describe una posible implementación de las

Nosotros proponemos unas ligeras modificaciones de las opciones SACK

Mathis, et al. Informativo [Pág. 3]

RFC 2018 Notificación de recepción selectiva Octubre 1996

Esta extensión de notificación de recepción selectiva emplea dos

La opción SACK se incluye en un segmento enviado desde una conexión

RFC 2018 Notificación de recepción selectiva Octubre 1996

La opción SACK-Permitted en TCP:

RFC 2018 Notificación de recepción selectiva Octubre 1996

3. Formato de la opción SACK

La opción SACK se empleará para transportar información extendida

Opción SACK en TCP:

La opción SACK se enviará por un receptor de datos para informar al

Esta opción contiene una lista de algunos de los bloques de

Cada bloque continuo de datos encolados en el receptor de datos está

o Borde izquierdo del primer bloque: Es el primer número de la

Mathis, et al. Informativo [Pág. 6]

RFC 2018 Notificación de recepción selectiva Octubre 1996

secuencia de este bloque.

o Borde derecho del primer bloque: Es el número de la secuencia que

Cada bloque representa los bytes de datos recibidos que están

La opción SACK es solo informativa, por tanto, aunque notifique al

Mathis, et al. Informativo [Pág. 7]

RFC 2018 Notificación de recepción selectiva Octubre 1996

4. Generando opciones SACK: Comportamiento del receptor de datos

Si el receptor de datos ha recibido la opción SACK-Permitted en el

Si el receptor de datos escoge enviar una opción SACK, se aplican las

o El primero bloque SACK (es decir, el que sigue inmediatamente a

o El receptor de datos DEBE incluir en la opción SACK, tantos

Mathis, et al. Informativo [Pág. 8]

RFC 2018 Notificación de recepción selectiva Octubre 1996

Es muy importante que la opción SACK siempre informe el bloque que

RFC 2018 Notificación de recepción selectiva Octubre 1996

5. Interpretando la opción SACK y la estrategia de retransmisión:

Cuando un ACK recibido contiene una opción SACK, el remitente de los

Una posible implementación del comportamiento del remitente es la

Cuando se recibe un segmento de confirmación de recepción con una

Después que el bit SACKed se activa (como resultado de procesar una

Después de agotarse el tiempo de espera de una retransmisión el

5.1 Aspectos sobre el control de congestiones

Este documento no pretende especificar en detalle los algoritmos de

Mathis, et al. Informativo [Pág. 10]

RFC 2018 Notificación de recepción selectiva Octubre 1996

control de congestión para la implementación del protocolo TCP con

El uso de tiempos de espera como un mecanismo de detección de