Resumen

  • Link-Quality-Report dio a los extremos PPP una mecánica común para calcular pérdidas de paquetes y octetos en ambos sentidos, sin convertir ese cálculo en una política universal de disponibilidad.
  • Cada informe enlazaba los totales de salida del emisor con observaciones guardadas por el receptor y devueltas después; las diferencias entre informes, no un valor inicial absoluto, sostenían la comparación.
  • La negociación era direccional y opcional, los contadores de 32 bits podían dar la vuelta, el Magic-Number sólo ayudaba a detectar bucles y RFC 1989 no definía seguridad ni recuperación obligatoria.

La misma pérdida no tenía el mismo precio

En una central de acceso, una línea con pérdida moderada puede seguir siendo el único camino hacia un cliente. En un router con respaldo disponible, esa misma pérdida puede justificar un cambio inmediato de ruta. Para una aplicación interactiva será grave; para una transferencia que reintenta, quizá no. Un protocolo que fijara un único umbral confundiría medición con valor operativo.

PPP eligió una frontera más pequeña. RFC 1333 publicó Link Quality Monitoring en mayo de 1992, y RFC 1989 lo sustituyó en agosto de 1996. El texto posterior separa explícitamente el mecanismo de la política. Estandariza el paquete Link-Quality-Report, sus puntos de conteo y su uso. Deja a cada implementación decidir cuándo la calidad es insuficiente y qué hacer entonces.

La interoperabilidad no exigía idéntica tolerancia. Exigía que ambos equipos pudieran reconstruir una historia comparable de los dos sentidos de la línea. El estándar creó esa base común sin convertir al IETF en operador de cada circuito.

Pedir informes no era prometer reciprocidad

La supervisión estaba desactivada por defecto. Un extremo que quería información incluía Quality-Protocol, opción LCP tipo 4, en su Configure-Request. El valor hexadecimal c025 seleccionaba Link Quality Report. Al responder Configure-Ack, el par aceptaba enviar ese protocolo.

La petición tenía dirección: “envíame informes”. No significaba “yo también te enviaré los mismos”. Cada sentido podía negociarse por separado, y RFC 1661 admitía incluso protocolos de calidad diferentes en los dos sentidos. Sin embargo, quien aceptaba enviar LQR también debía procesar correctamente los que recibiera, aunque no hubiese pedido informes ni aplicase una política propia.

La variante LQR añadía un Reporting-Period de cuatro octetos, expresado en centésimas de segundo. Era el intervalo máximo permitido, de modo que el par podía informar antes. Cero eliminaba el temporizador y ordenaba responder de inmediato a un LQR entrante. La negociación impedía que ambos lados eligieran cero y quedaran esperando para siempre.

El acuerdo tenía un final definido. Si llegaba un Protocol-Reject referido a LQR, el proceso debía dejar de enviarlos. Por ello, un Ack capturado demuestra aceptación en un momento concreto; no demuestra que los informes posteriores cruzaran una línea degradada.

Un informe contenía el presente y un eco del pasado

Los nombres de los campos se entienden desde quien recibe el LQR. PeerOutPackets, PeerOutOctets y PeerOutLQRs son los totales de salida actuales del emisor. Al recibir el paquete, el proceso local añade lógicamente SaveInPackets, SaveInOctets, descartes, errores y SaveInLQRs. Esos campos SaveIn no viajaron por el enlace entrante: registran lo que el receptor vio en su propio punto de medición.

Más tarde, cuando ese receptor envía en la dirección contraria, devuelve sus observaciones guardadas como PeerIn.... Los campos LastOut... copian la última visión recibida de las salidas locales anteriores. Así, cada lado obtiene tanto la declaración actual del otro como la huella de lo que el otro dijo haber recibido.

Los contadores son acumulativos. Restar dos informes consecutivos produce intervalos comparables. La variación de PeerInPackets frente a LastOutPackets estima paquetes perdidos en la salida local. SaveInPackets frente a PeerOutPackets estima la pérdida entrante. Los octetos aportan una segunda medida. Descartes y errores comunicados por el par pueden indicar que parte de la pérdida ocurrió en un receptor congestionado y no en el medio físico.

Es una reconciliación, no un recibo firmado por paquete. Reduce el conjunto de explicaciones compatibles con la evidencia, pero no garantiza una causa ni la honestidad del par.

Hasta la palabra «octeto» necesitaba un contrato

PPP podía ejecutarse en software, en procesos separados o con hardware que ocultaba el tramado. Un convertidor síncrono-asíncrono podía cambiar la representación visible. Si cada producto copiaba un contador físico distinto, la diferencia entre equipos parecería pérdida aunque los datos hubieran llegado.

RFC 1989 estableció una cuenta de referencia. Se incluyen los octetos cubiertos por FCS, el propio FCS y una bandera por trama. Se excluyen banderas adicionales y los bits u octetos de escape. La intención no era medir todo el ancho de banda físico, sino obtener una cantidad reproducible de información. InGoodOctets no incluye tramas descartadas o erróneas.

Al insertar los totales, el equipo ya cuenta la contribución esperada del LQR que está construyendo. Los campos de 32 bits crecen y después vuelven a cero; el cálculo debe reconocer esa vuelta. Además, ciertos contadores de interfaz no se reinician al mismo valor cuando LCP entra en establecimiento. La sincronización procede de las diferencias, no de suponer un cero compartido.

Una unidad mal definida contamina toda política posterior. Una fuga de escape contada en un lado, o una resta firmada durante la vuelta a cero, puede fabricar una pérdida que nunca existió.

Un informe perdido también era parte del problema

LQR recibía la mayor prioridad en el multiplexor para que la evidencia llegara a tiempo. Aun así, no existía una frecuencia perfecta. Cuando la línea funciona bien, informar demasiado consume capacidad sin añadir valor. Una ventana larga suaviza ráfagas de pérdida, pero tarda más en reconocer una interrupción total.

La dirección de la avería cambia la utilidad de acelerar. Si los LQR entrantes llegan y revelan una salida muy mala, enviar más rápido hacia el par probablemente sólo genere más informes perdidos. Si la salida funciona y la entrada falla, varios intentos pueden conseguir que alguno llegue y que el par forme su propia conclusión.

Un silencio no autorizaba una condena instantánea. RFC 1989 pedía al menos un LQR adicional cuando faltaba el esperado o cuando el recibido mostraba una situación realmente mala. Una decisión algorítmica necesitaba como mínimo dos intervalos de ida y vuelta: una sobrecarga transitoria o la pérdida del propio informe podían explicar la primera alarma.

El documento sugería histéresis y ofrecía K éxitos de N periodos como ejemplo. No fijaba K, N ni el umbral. Tampoco ordenaba una recuperación. Cerrar los protocolos de red y mantener LQR era una propuesta; cambiar ruta, desconectar o esperar pertenecían a la política local.

c025 identificaba un formato, no una identidad

Cuando se había negociado Magic-Number, el LQR podía revelar un bucle al devolver el número propio. Sin negociación, el campo era cero y se ignoraba. Igual que en LCP, ese número ayudaba a reconocer una anomalía de enlace; no autenticaba al equipo ni a su organización.

RFC 1989 dice que no discute las cuestiones de seguridad. No añade integridad criptográfica al informe ni una credencial para sus contadores. La autenticación PPP vive en otra fase. Ver c025 en una captura prueba que allí apareció una representación LQR; no prueba que sus valores sean una verdad externa ni que una aplicación haya recibido tráfico.

Por eso una bitácora útil mantiene separados el Configure-Request, el Ack o Reject, el periodo, la llegada real, los valores crudos, la corrección por vuelta a cero, las diferencias, la versión de política y la acción. Reducir todo a una luz roja elimina la autoría del veredicto.

Compartir pruebas sin centralizar decisiones

La importancia histórica de LQR está en la modestia de su consenso. PPP no intentó convertir los requisitos de todos los servicios en un número. Definió lo que los pares debían compartir para hablar de pérdida con el mismo vocabulario. Sobre esa base, cada extremo podía experimentar y operar según su topología.

La asignación c025 de IANA demuestra identidad de protocolo. El Configure-Ack demuestra aceptación de un deber de informar. Las diferencias de contadores apoyan una estimación. Los descartes y errores afinan la hipótesis. Después comienza otra cadena: una regla local declara el estado y la evidencia de ruta, NCP, enlace y aplicación muestra si la respuesta tuvo efecto.

LQR permitía discutir sobre una base común. Nunca declaró que la base común contuviera la decisión final.

Fuentes