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 Petición de Comentarios: 2018 Categoría: Informativo

M. Mathis J. Mahdavi 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. distribución de este memorándum no está limitada.

La

Nota de Copyright Copyright (C) The Internet Society (1996). reservados.

Todos los derechos

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. RFC 2018

Informativo Notificación de recepción selectiva

[Pág. 1] 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. 2. 3. 4.

Introducción . . . . . . . . . . . . . . . . . . . . La opción SACK-Permitted . . . . . . . . . . . . . . Formato de la opción SACK . . . . . . . . . . . . . Generando opciones SACK: Comportamiento del receptor datos . . . . . . . . . . . . . . . . . . . . . . . 5. Interpretando la opción SACK y la estrategia de retransmisión: Comportamiento del remitente de datos 5.1 Aspectos sobre el control de congestiones . . . . .

. . . . . . de . .

. . . . . . . . .

3 5 6

. . .

8

. . . . . 10 . . . . . 10

6. 7. 8. 9. A.

Eficiencia y comportamiento del peor caso . Ejemplos de opciones SACK . . . . . . . . . Renuncia por parte del receptor de los datos Consideraciones de seguridad . . . . . . . . Referencias . . . . . . . . . . . . . . . . Dirección de los autores . . . . . . . . . . Créditos de la traducción y conversión a XML Declaración completa de Copyright . . . . .

Mathis, et al. RFC 2018

. . . . . . . .

Informativo Notificación de recepción selectiva

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

12 13 15 16 17 18 19 20

[Pág. 2] Octubre 1996

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.

Mathis, et al. RFC 2018

Informativo Notificación de recepción selectiva

[Pág. 3] Octubre 1996

Esta extensión de notificación de recepción selectiva emplea dos opciones TCP. La primera es una opción de habilitación, «SACKpermitted», 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.

Mathis, et al. RFC 2018

Informativo Notificación de recepción selectiva

[Pág. 4] Octubre 1996

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 | +---------+------------+

Mathis, et al. RFC 2018

Informativo Notificación de recepción selectiva

[Pág. 5] Octubre 1996

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

Mathis, et al. RFC 2018

Informativo Notificación de recepción selectiva

[Pág. 6] Octubre 1996

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.

Mathis, et al. RFC 2018

Informativo Notificación de recepción selectiva

[Pág. 7] 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 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.

Mathis, et al. RFC 2018

Informativo Notificación de recepción selectiva

[Pág. 8] Octubre 1996

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.

Mathis, et al. RFC 2018

Informativo Notificación de recepción selectiva

[Pág. 9] Octubre 1996

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

Mathis, et al. RFC 2018

Informativo Notificación de recepción selectiva

[Pág. 10] Octubre 1996

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.

Mathis, et al. RFC 2018

Informativo Notificación de recepción selectiva

[Pág. 11] Octubre 1996

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].

Mathis, et al. RFC 2018

Informativo

[Pág. 12]

Notificación de recepción selectiva

Octubre 1996

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

5000 5500 6000 6500 7000 7500 8000 8500

izquierdo

(perdido) 5000 5000 5000 5000 5000 5000 5000

derecho

5500 5500 5500 5500 5500 5500 5500

6000 6500 7000 7500 8000 8500 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:

Mathis, et al.

Informativo

RFC 2018

Primer bloque

que se

Borde derecho

6500

Notificación de recepción selectiva Segmento

bloque

[Pág. 13]

envía

Borde ACK

5000 5500 6000 6500 7000 7500 8000

5500 (perdido) 5500 (perdido) 5500 (perdido) 5500

8500

(perdido)

Segundo bloque

Borde

izquierdo derecho

Octubre 1996

Borde

Borde

izquierdo derecho

Tercer Borde

izquierdo

6000

6500

7000

7500

6000

6500

8000

8500

7000

7500

6000

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 que se

Primer bloque Borde Borde

Segundo bloque Borde Borde

Tercer bloque Borde Borde

derecho

envía

ACK

6500

izquierdo derecho 5500

6000

izquierdo derecho

7500

8000

izquierdo

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 bloque

que se

Borde

envía

ACK

5500

7500

Primer bloque

Segundo bloque

Tercer

Borde

Borde

Borde

Borde

izquierdo derecho

Borde

izquierdo derecho

izquierdo

derecho

Mathis, et al. RFC 2018

8000

8500

Informativo Notificación de recepción selectiva

[Pág. 14] Octubre 1996

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 Incluso si el segmento más ha descartado ya segmentos informar, como mínimo, los más nuevo.

reflejar el segmento más nuevo. nuevo va a ser descartado y el receptor adyacentes, el primer bloque SACK DEBE bordes izquierdo y derecho del segmento

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.

Mathis, et al. RFC 2018

Informativo Notificación de recepción selectiva

[Pág. 15] Octubre 1996

9. Consideraciones de seguridad Este documento ni mejora ni empeora las características actuales de seguridad del protocolo TCP.

Mathis, et al. RFC 2018

Informativo Notificación de recepción selectiva

[Pág. 16] Octubre 1996

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]



[17]



Mathis, et al. RFC 2018

Informativo Notificación de recepción selectiva

[Pág. 17] Octubre 1996

[18]



[19]



[20]

<mailto:[email protected]>

Dirección de los Autores Matt Mathis Pittsburgh Supercomputing Center 4400 Fifth Ave Pittsburgh, PA 15213 US EMail: [email protected] Jamshid Mahdavi Pittsburgh Supercomputing Center 4400 Fifth Ave Pittsburgh, PA 15213 US

EMail: [email protected] Sally Floyd Lawrence Berkeley National Laboratory One Cyclotron Road Berkeley, CA 94720 US EMail: [email protected] Allyn Romanow Sun Microsystems, Inc. 2550 Garcia Ave. MPK17-202 Mountain View, CA 94043 US EMail: [email protected]

Mathis, et al. RFC 2018

Informativo Notificación de recepción selectiva

[Pág. 18] Octubre 1996

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.

Mathis, et al. RFC 2018

Informativo

[Pág. 19]

Notificación de recepción selectiva

Octubre 1996

Declaración completa de Copyright Copyright (C) The Internet Society (1996). derechos.

Reservados todos los

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.

Mathis, et al.

Informativo

[Pág. 20]