Resumen

  • RFC 3465 propuso Appropriate Byte Counting: ampliar la ventana TCP por los bytes antes no confirmados que cubría cada ACK, en vez de otorgar un incremento fijo a cada mensaje ACK.
  • La prueba de bytes seguía acotada. L limitaba el aumento por ACK durante slow start, nunca podía superar dos SMSS y debía ser un SMSS después de un RTO, cuando una confirmación acumulativa podía incluir progreso antiguo.

Contar recibos distorsionaba el avance

El crecimiento tradicional de cwnd usaba cada ACK como una oportunidad. La aproximación funcionaba si el receptor confirmaba todos los segmentos y no se perdían avisos. Pero un receptor que retrasaba ACK enviaba menos mensajes para los mismos bytes. Otro podía dividir la confirmación de un segmento entre varios ACK y fabricar más oportunidades. La unidad administrativa había empezado a gobernar la capacidad.

El RFC 3465, publicado como Experimental en febrero de 2003, cambió esa contabilidad. El texto plano, el registro RFC Editor, la ficha Datatracker, el historial, las referencias, las citas posteriores y las erratas fijan su expediente. Modificaba la lógica del RFC 2581, cuyo sucesor normativo fue el RFC 5681.

Los ACK retrasados permitidos por el RFC 1122 podían cubrir dos segmentos completos. Bajo conteo de mensajes, la ventana crecía aproximadamente la mitad de rápido. Si se perdía un ACK, también se perdía una oportunidad aunque el siguiente confirmase acumulativamente los mismos datos.

La división de ACK explotaba el extremo contrario. El receptor enviaba varias confirmaciones para porciones sucesivas de un segmento. Si cada mensaje añadía una cantidad fija a cwnd, los mismos bytes creaban crédito repetido. ABC hizo que las muchas piezas sumasen solo el progreso real que contenían.

El emisor llevaba un libro de bytes

Durante congestion avoidance, bytes_acked acumulaba únicamente bytes antes no confirmados. Al alcanzar el cwnd actual, el emisor restaba esa cantidad y aumentaba la ventana en un SMSS. Así conservaba aproximadamente un segmento de crecimiento por RTT sin depender de cuántos ACK transportaban el avance.

En slow start, el aumento podía igualar los nuevos bytes de un ACK, con el límite L. L=1*SMSS no era más agresivo que la regla anterior y fue la forma recomendada. L=2*SMSS se permitía para experimentar y compensar el ACK de cada dos segmentos; un valor mayor quedaba prohibido.

El límite contenía los stretch ACK y los grandes acumulativos. Aun con dos SMSS, ABC podía liberar micro-ráfagas mayores y hacer que slow start se acercara al doble por vuelta. Las simulaciones limitadas del RFC observaron más pérdidas en algunos casos y pidieron experimentación; no demostraron adopción ni justicia general. El documento recomendó SACK, definido en RFC 2018. La validación de ventana del RFC 2861 abordó la acumulación de crédito no usado en conexiones limitadas por la aplicación.

Tras un RTO, el pasado podía reaparecer

Si un segmento se perdía y los posteriores ya estaban en el receptor, la retransmisión del hueco podía provocar un ACK acumulativo que cruzaba varios segmentos. Todos eran nuevos para el estado de confirmación del emisor, pero no todos habían salido de la red en el RTT actual. Por eso RFC 3465 obligaba a usar L=1*SMSS en la recuperación por slow start posterior a un RTO.

El RFC 2988, sustituido después por el RFC 6298, daba el contexto del temporizador. La confirmación seguía siendo válida; lo que cambiaba era su autoridad temporal como prueba de capacidad reciente.

Otros mecanismos tenían otra jurisdicción. RFC 3042 permitió Limited Transmit antes del tercer ACK duplicado bajo límites concretos; no definió el libro ABC. RFC 3449 trató asimetría, filtrado y reconstrucción de ACK; no reasignó el crédito del emisor. El catálogo de RFC 2525 aporta contexto de fallos de implementación, no evidencia de despliegue.

Las posteriores capas de realidad de Heng Lu ayudan a separar mensaje observado, bytes nuevos, crédito admitido y paquetes emitidos. La prioridad del código ejecutado obliga a mirar acumulador, límite, recuperación y ráfaga. Son lentes editoriales posteriores, no una atribución de intención privada.

RFC 3465 hizo la cuenta menos manipulable y también limitó su poder. El número de avisos podía cambiar; los bytes demostrados no debían multiplicarse con ellos.

Fuentes