Resumen

  • MAX_DATA y MAX_STREAM_DATA anuncian límites absolutos de offset, no bytes nuevos ni memoria libre.
  • Un valor posterior menor no revoca crédito, y la ausencia de DATA_BLOCKED no demuestra que el emisor tenga margen.
  • Para hablar de capacidad hay que unir crédito, offsets, tamaños finales, consumo de la aplicación, memoria y congestión.

Un panel observa que MAX_DATA sube a 16 MiB y registra 16 MiB de holgura. El cálculo confunde un límite acumulativo con un incremento: los offsets ya usados siguen contando. La lectura semántica también falla. El número autoriza al emisor a ampliar su contabilidad de bytes; no mide por sí solo RAM disponible ni trabajo consumido por la aplicación.

La RFC 9000 §4.1 aplica dos techos simultáneos. El de conexión limita todos los datos STREAM y el de flujo evita que un flujo agote el búfer. El permiso efectivo depende del mayor límite de conexión, su consumo acumulado, el límite del flujo concreto y su mayor offset contabilizado.

Los valores son absolutos. Un MAX_DATA o MAX_STREAM_DATA menor no tiene efecto; el emisor debe ignorar cualquier trama que no aumente el máximo. Por ello, «último valor» no es una métrica válida. El registro debe conservar el mayor valor aceptado y el consumo asociado.

La RFC 9000 §19.9 incluye todos los datos STREAM y exige que la suma de tamaños finales, incluso de flujos terminados, quede bajo el máximo. La RFC 9000 §4.5 define el tamaño final como crédito consumido. Cerrar o reiniciar un flujo fija la cuenta; no devuelve mágicamente sus offsets al presupuesto de conexión.

La RFC 9000 §19.10 usa el mayor offset del flujo. Pérdidas y reordenación pueden adelantarlo respecto de los bytes contiguos ya entregables. Ni los bytes brutos de paquetes ni la ocupación instantánea del búfer sustituyen esa contabilidad.

La RFC 9000 §4.2 deja a la implementación decidir cuándo y cuánto crédito ampliar. Actualizaciones pequeñas y frecuentes añaden sobrecarga; menos actualizaciones exigen incrementos y compromisos de recursos mayores. El autoajuste puede usar RTT y la tasa de consumo de la aplicación, pero esos insumos no convierten el máximo anunciado en un sensor de memoria libre.

Tampoco promete caudal. La RFC 9000 §4.3 advierte que el flujo limita el rendimiento cuando el crédito disponible no supera el producto ancho de banda-retardo. El crédito puede ser necesario sin ser suficiente: ventana de congestión, pérdida, planificación y trabajo del emisor siguen mandando.

DATA_BLOCKED es una señal incompleta. Según la RFC 9000 §19.12, el emisor debería enviarla cuando quiere escribir y el límite de conexión lo impide. Sin embargo, no está obligado, y §4.2 prohíbe al receptor esperar esa trama antes de ampliar crédito. Su ausencia no es prueba de disponibilidad.

El registro defendible reúne máximos, consumo acumulado, offsets, tamaños finales, bloqueos observados, frontera de consumo de la aplicación, ocupación de memoria, ventana de congestión, RTT, pérdidas y tiempos de actualización. MAX_DATA solo acredita el permiso de protocolo.