Resumen
- En el TCP clásico de RFC 3168, el receptor continúa poniendo ECE en los acuses después de ver CE, hasta recibir un segmento nuevo de datos con CWR.
- Una sola observación CE puede originar numerosos ACK con ECE; expresan un estado de realimentación resistente a pérdidas, no igual número de episodios.
- Durante el establecimiento, ECE y CWR negocian capacidad, y la presencia de túneles o experimentos posteriores impide usar la cifra bruta como atribución universal.
El aviso persiste porque un acuse puede perderse
Supongamos que una sonda registra seis ACK consecutivos con ECE. Es correcto afirmar que observó seis paquetes con esa bandera. No lo es convertirlos automáticamente en seis marcas de una cola. RFC 3168 hace que el receptor recuerde una observación precisamente para no depender de un solo paquete de retorno.
En una conexión ya establecida, un paquete de datos con el código Congestion Experienced provoca que el receptor active ECE en su acuse. Si el receptor agrupa varios segmentos mediante un ACK demorado, basta con que uno estuviera marcado para que ese acuse lleve ECE. Después continúa activándolo en los ACK siguientes, aun cuando estos correspondan a datos posteriores sin CE.
La serie termina cuando llega la respuesta CWR del emisor. Hasta entonces, la bandera no representa nuevas mediciones independientes: representa la vigencia de una notificación. La unidad fiel es un intervalo con una apertura, una persistencia y un cierre. El hueco causado por un ACK perdido no anula el mensaje porque otro ACK posterior puede repetirlo.
La respuesta del emisor no se multiplica con cada paquete
Según el comportamiento clásico, el emisor interpreta ECE como señal de congestión y reduce su ventana de modo comparable a la reacción ante pérdida. Sin embargo, no debe realizar una reducción por cada ACK que repite ECE. Para una serie de pérdidas o indicaciones CE dentro de una ventana de datos, aproximadamente un tiempo de ida y vuelta, corresponde una sola reacción de ventana.
Tras reducirla, el emisor coloca CWR en el primer segmento nuevo de datos. RFC 3168 aconseja no usar para ello una retransmisión. Cuando el receptor recibe ese segmento nuevo, borra el estado: deja de poner ECE en los acuses de datos posteriores no marcados. Otra marca CE puede iniciar un intervalo distinto.
Si el segmento portador de CWR se pierde, la repetición de ECE conserva la oportunidad de respuesta y más tarde puede aparecer otro CWR. Por eso un mismo episodio puede producir muchos paquetes en ambos sentidos. CWR respalda que el emisor reaccionó después de enviar los datos implicados; no demuestra qué ACK ECE concreto recibió ni qué dispositivo originó la marca.
La negociación usa el mismo vocabulario con otra sintaxis
Antes de los datos, las banderas tienen otra función. El iniciador envía un SYN con ECE y CWR a la vez para solicitar ECN. Un receptor capaz responde con ECE activo y CWR inactivo en el SYN-ACK. En ese momento ECE declara capacidad; no informa de congestión sufrida por el SYN.
Si una canalización descarta la fase y guarda solo el valor booleano de ECE, inventará una congestión al principio de cada conexión ECN negociada. Deben preservarse dirección, estado TCP y combinación completa de banderas. Además, negociar la capacidad no obliga por sí solo a que cada futuro paquete saliente use un código ECT.
Hay una asimetría adicional: en RFC 3168 los ACK puros se envían Not-ECT. El estado ECE procede de observaciones realizadas sobre datos del trayecto de ida; no ofrece un inventario equivalente de la congestión sufrida por el trayecto de retorno.
El eco tampoco identifica la cola
Una cola activa puede marcar en lugar de descartar durante congestión leve o moderada, y puede hacerlo antes de llenarse, como explica RFC 7567. La marca no prueba desbordamiento, pérdida, latencia concreta ni umbral de una caja determinada. Cada una de esas conclusiones exige evidencia adicional.
Los túneles separan aún más señal y lugar. Dentro de un túnel, un nodo puede marcar solo la cabecera externa visible. RFC 6040 indica cómo los extremos combinan los campos ECN externo e interno para trasladar la información. El ECE final puede ser auténtico sin revelar dónde apareció CE.
Tampoco debe confundirse con los ACK duplicados de RFC 5681. Esos acuses responden a otras condiciones y pueden proceder de pérdida, reordenamiento o replicación. Número de ACK, secuencias, retransmisión, ECE, CWR y tiempo son observaciones distintas.
RFC 8311, por último, permite experimentos documentados que flexibilizan restricciones del diseño original. Este análisis describe el contrato TCP clásico de RFC 3168, no todas las variantes de ECN ni todos los transportes que puedan emplear marcas.
Fuentes
- Perfil IETF de K. K. Ramakrishnan
- RFC 3168: incorporación de la notificación explícita de congestión a IP
- RFC 5681: control de congestión TCP
- RFC 6040: transporte de ECN a través de túneles IP
- RFC 7567: recomendaciones de gestión activa de colas
- RFC 8311: flexibilización de las restricciones para experimentar con ECN
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
