Resumen

  • La RFC 1363 diseñó una especificación de flujo para que un extremo solicitara servicios especiales, entre ellos los que podía necesitar una conferencia multimedia. Cada dirección exigía su propia solicitud.
  • El retardo indicado servía para señalar cuándo dejar de intentar mejorarlo. La red debía responder también qué clase de garantía podía ofrecer: una pista, una promesa imperfecta, servicio previsto o garantía firme.

El número parecía fácil de vender: 100 milisegundos. Craig Partridge lo volvió incómodo en la RFC 1363 de septiembre de 1992. En su ejemplo, ese tiempo podía parecer magnífico entre Estados Unidos y Japón y deficiente dentro de una misma ciudad. Ninguna de las dos situaciones era una medición de una llamada concreta. Era una prueba de lógica para cualquier contrato que pretendiera ignorar la distancia y pedir a todas las rutas la misma llegada.

La propuesta nacía de un problema nuevo para una red acostumbrada a entregar paquetes sin prometer ritmo: conferencias multimedia, visualización y otras tareas distribuidas necesitaban anticipar caudal, retardo y pérdidas. Un host podía negociar antes de enviar, durante la apertura de la comunicación o mientras ya transmitía. El documento no escogió una ceremonia única. Se concentró en la hoja que el solicitante pondría sobre la mesa para que la respuesta fuese inteligible.

La hoja describía un solo sentido. Una conversación de ida y vuelta necesitaba dos especificaciones. El campo Minimum Delay Noticed tampoco era el plazo máximo para que llegase un paquete. Indicaba el punto por debajo del cual reducir el retardo dejaba de aportar valor apreciable a la aplicación. La geografía del trayecto podía ser desconocida para la red, y los hosts móviles harían todavía más difícil fijar un máximo racional. Partridge añadía una observación poco cómoda para el eslogan de los 100 milisegundos: las personas podían continuar hablando con retrasos de varios segundos si la alternativa era no comunicarse.

Antes de pedir velocidad, el emisor tenía que declarar lo que enviaría. Tasa sostenible de un cubo de fichas, tasa máxima y tamaño aproximado de ráfaga describían la carga. La RFC daba una comparación que no dependía de gustos: un flujo superior a 10 megabits por segundo no cabía en un enlace T1 de 1,5 megabits por segundo. Un encaminador podía rechazar esa ruta sin debatir qué retardo subjetivo aceptaría el usuario.

La recepción introducía otro coste. Una voz producida a intervalos regulares podía llegar con pausas desiguales por las colas del camino. El receptor necesitaba memoria para reconstruir el ritmo; la variación de retardo especificaba cuánta estaba dispuesto a emplear. El cálculo del documento relacionaba la amplitud de esa variación con la tasa de transmisión. Las pérdidas se describían por intervalo y por ráfaga consecutiva. Dos rutas con el mismo porcentaje total podían estropear una conversación de manera distinta si una perdía varios paquetes seguidos.

La palabra «garantía» exigía su propia casilla. Quality of Guarantee distinguía la ausencia de promesa firme, una garantía imperfecta, servicio previsto y servicio garantizado. Partridge citaba experimentos de conferencia de la IETF: un último salto Ethernet podía funcionar bien, pero nada impedía que se saturase durante la sesión. Una ruta con ese salto era útil sin estar respaldada en cada tramo. En el servicio previsto, equipos cooperantes aceptaban una pequeña degradación bajo carga; en la garantía imperfecta, un tramo no cooperante podía fallar sin ese compromiso estadístico.

Para una solicitud que exigía firmeza, el modelo esperaba un sí o un no. La aplicación pedía el servicio mínimo aceptable y la red aceptaba o rechazaba el flujo. Partridge temía que regatear por todas las rutas posibles al principio de cada llamada prolongara el establecimiento. Una respuesta negativa podía devolver una hoja modificada como sugerencia, sin prometer que esa variante se hubiese reservado.

La RFC definió la gramática de la petición, no una red pública que ya concediera tales reservas. Su apuesta más incisiva fue obligar al solicitante y al operador a hablar de cosas diferentes con nombres diferentes. Cien milisegundos eran una preferencia hasta que el trayecto, el tráfico, la memoria del receptor y la clase de garantía les dieran contenido.

Fuentes: RFC 1363; registro oficial de RFC 1363.