Resumen

  • En la versión del 30 de septiembre, el borrador del grupo MASQUE obliga a descartar la trama que supera la capacidad disponible de QUIC DATAGRAM y prohíbe enviarla como cápsula DATAGRAM a modo de rescate. También obliga a descartar, con independencia del modo, una trama que supere el límite de la interfaz de salida, la red de destino o el receptor; recomienda contar esos descartes.
  • La versión anterior incluía el Frame Check Sequence o FCS dentro de la trama transmitida. La nueva delimita la carga justo antes del FCS, que las interfaces de red suelen quitar al recibir y regenerar al transmitir. El documento sigue siendo un Internet-Draft sometido al examen del IESG, no un RFC aprobado ni una prueba de fallos reales.

La discusión práctica no empieza en el cifrado ni en el nombre del túnel, sino en una factura de servicio: ¿qué significa que el proveedor anuncie «túnel disponible»? Significa que se estableció una sesión, no que cada trama que llega al borde cabe en el transporte elegido. La revisión 15 permite separar esas dos afirmaciones con condiciones comprobables. Una luz verde en HTTP no es una medición de admisión de tramas.

CONNECT-ETHERNET propone intercambiar tramas de capa 2 a través de un servidor HTTP. Si se usa HTTP/3 con la extensión QUIC DATAGRAM, el paquete no puede fragmentarse en varios datagramas. Del espacio máximo hay que restar la sobrecarga del formato HTTP Datagram. Por eso, comparar solo con una MTU nominal puede dar una falsa impresión de capacidad. Cuando la trama recién llegada excede el espacio efectivo, el extremo tiene que perderla; el texto añade que no puede convertir esa trama concreta en una cápsula. El descubrimiento de MTU a lo largo de la conexión puede ayudar a ajustar la interfaz, pero no borra la pérdida ya ocurrida.

Las cápsulas no desaparecen. HTTP/1.1, HTTP/2 y HTTP/3 sin QUIC DATAGRAM las llevan en un flujo fiable, donde una trama puede repartirse entre varios paquetes TCP o QUIC y superar la MTU de un paquete de la ruta. Esa ventaja pertenece al modo que se haya adoptado; no autoriza un cambio silencioso de modo por cada trama demasiado grande. Una prueba de interoperabilidad basada en tramas pequeñas podría confirmar el establecimiento del túnel y, sin embargo, omitir el límite que afectará a la carga real.

El otro umbral está después de la decapsulación. Puede haber espacio en el túnel, pero no en la interfaz física o virtual que debe recibir la trama reconstruida. El borrador exige descartarla si excede cualquiera de los límites de salida que enumera, y aconseja mantener un contador de tramas sobredimensionadas perdidas. Conviene distinguir ese contador del de entrada: uno señala un problema de capacidad del QUIC DATAGRAM; el otro, una incompatibilidad con el medio de salida. Ninguno prueba por sí mismo por qué una aplicación no respondió.

La comparación de las versiones también revela un cambio de representación. La versión 14 describía una trama Ethernet que incluía el FCS. La 15, para el identificador de contexto cero, va desde la dirección de destino hasta el último byte anterior a ese campo. Su explicación es operacional: las tarjetas de red habituales eliminan el FCS al recibir y generan otro al transmitir. No es una afirmación de que Ethernet carezca de protección frente a errores ni de que el túnel sea inseguro por definición. Sí impide presentar el FCS original como un comprobante preservado de extremo a extremo por este formato.

Una extensión posterior podría definir otra codificación.

El documento delimita el túnel como enlace punto a punto emulado. Si se une a redes Ethernet más amplias, el puenteo, los bucles y la gestión de tráfico de difusión quedan en los extremos o en los componentes a los que se deleguen. Las etiquetas VLAN se reenvían normalmente; si se interpretan, los extremos necesitan acordar una política que el borrador no especifica. Que una VLAN pueda asociarse a una URI propia es una opción de control, no una garantía de aislamiento o de entrega.

La ficha oficial mantiene el borrador activo, enviado por el grupo MASQUE al IESG y en seguimiento del director de área, con una objeción DISCUSS pendiente. Aspira a Proposed Standard, pero todavía es un documento de trabajo. Nada en estas páginas mide despliegues, describe un operador concreto o demuestra una avería. La noticia es la precisión del contrato propuesto y la pregunta que deja a los operadores: ¿pueden mostrar dónde se admitió o se rechazó una trama sin confundirlo con el éxito de HTTP?

Fuentes