David L. Mills y el legado fundamental del protocolo de tiempo de red (NTP)

21/02/2024

Por Carlos Martinez Cagnazzo, Gerente de Tecnología de LACNIC

Pocos días atrás, el científico informático David L. Mills -inventor del NTP (Network Time Protocol)- falleció en su casa de Newark, Delaware (US) a los 85 años de edad.

La ocasión, es oportuna para hablar de un sistema que permite a las computadoras conectadas a Internet sincronizar sus relojes, una tecnología fundamental en la que se basa toda la Internet moderna, aunque no tenga ni la prensa ni la fama de otros protocolos de Internet.

En la década de 1970, varios investigadores estaban construyendo Arpanet, una de las primeras versiones de la web patrocinada por el gobierno de US que conectaba varios nodos en universidades de todo el país. A medida que la red crecía y más máquinas se conectaban a ella, la falta de un sistema que asegurara que todas tuvieran la misma precisión en términos de tiempo empezaba a causar problemas, sobre todo si se quería utilizar la Red para transacciones o todo tipo de comunicaciones y flujo de información en tiempo real.

Debido a este desfase de tiempo impredecible, el Dr. Mills comenzó a trabajar en formas de sincronizar los tiempos de las computadoras. A finales de la década de 1970, NTP finalmente vio la luz.

Vale destacar que hay distintos lugares donde las sincronizaciones temporales son vitales.

Las redes telefónicas son una de las industrias pioneras en sincronizar relojes, de hecho, su sistema de coordinación temporal fue una de las fuentes de verdad que tomó el NTP. Estas redes contaban con mensajes de sincronización de relojes a nivel de los paquetes de control. Puntualmente, cada red telefónica tenía una referencia de tiempo -normalmente en la forma de un reloj atómico- que hasta el día de hoy sigue siendo la fuente de tiempo más precisa que existe.

Pero en el caso de las redes TCP/IP no existe mensajería de control de reloj que transporte información de sincronización. Justamente, ese es el rol del NTP, por ello lo utilizan todos los sistemas operativos, incluyendo Windows, Mac OS y los sistemas operativos embebidos en los dispositivos de red.

¿Dónde vemos que la sincronización del tiempo sea importante en el caso de Internet? Es crucial para los enlaces que conectan dispositivos. La llamada “deriva de reloj” o discrepancia en la sincronización entre los extremos puede provocar la caída de los enlaces. En el caso de los protocolos de enrutamiento, también es necesario un acuerdo de tiempos para evitar problemas. Para los certificados digitales y su ventana de validez, también se hace necesario una sincronización de relojes para evitar respuestas como “certificados no válidos”, “expirados”, etc.

Me gustaría destacar que sincronizar una red que ya por naturaleza espera sincronía -como lo que ocurre con las redes telefónicas- es relativamente más fácil que lo que ocurre con las redes IP, que son por naturaleza asíncronas y donde no existe un requisito de tiempo. Por este carácter asincrónico, nunca se sabe cuánto demora un paquete de datos en ir de origen a destino.

¿Cómo funciona una aproximación a un protocolo de tiempo en Internet al mandar un paquete? La respuesta sería la hora X del envío más el tiempo que le llevó a ese paquete el viaje de un lugar a otro. ¿Cuál es el problema? Que ese tiempo que hay que adicionar es incierto. La “magia” del algoritmo de NTP reside en crear una estructura que permite estimar ese tiempo con bastante precisión a través del enrutamiento de paquetes en redes con latencia variable.

Para evitar que los errores de cálculo se empiecen a acumular, NTP utiliza el algoritmo de Marzullo basado en la escala de tiempo UTC (tiempo universal coordinado) incluyendo soporte para características como segundos intercalares.

El servidor utiliza un sistema de jerarquía de estratos de reloj, en donde los sistemas de stratum 0 están sincronizados con un reloj externo cuya referencia es muy precisa e ineludible, como un reloj GPS o un reloj atómico. Los stratum 1 son los que sincronizan contra los del stratum 0, los sistemas de stratum 2 derivan su tiempo de uno o más de los sistemas de stratum 1 y así consecutivamente.

Es importante aclarar que como normalmente es muy oneroso operar un servidor de NTP stratum 0, lo que se hace es consumir sistemas de stratum 1 o 2. Además, existe un máximo de niveles de stratum -concretamente hasta 15- y a medida que aumenta el número de stratum, los dispositivos se vuelven menos precisos.

Vale destacar que los servidores NTP que están disponibles en la región o cerca de donde se encuentra el dispositivo ayudan a mejorar un poco más la precisión de los relojes. Se pueden conocer los servidores disponibles en sitios como NTP Pool Project que también ofrece a los interesados la oportunidad de unirse al proyecto. Adicionalmente el  El Proyecto NTP realiza Investigación y desarrollo en NTP: se trata de una comunidad muy bien constituida que produce una implementación de referencia de código abierto del estándar NTP, mantiene la documentación de implementación y desarrolla el protocolo y el estándar algorítmico que se utiliza para comunicar la hora entre sistemas.

Por último, me gustaría destacar que la contribución de Mills es una muestra de cómo funciona el proceso de innovación en Internet, que difiere un poco de lo que ocurre con otras tecnologías que son más reguladas y construidas “de arriba hacia abajo”, como en el caso de las redes telefónicas. 

La historia de Internet evidencia mucha más aleatoriedad: comenzó con un conjunto básico de protocolos y a medida que se hicieron falta, se fueron inventando espontáneamente protocolos como HTTP o DNS. Otro caso es lo que sucedió con IPv4 e IPv6, entre muchos otros ejemplos. La realidad es que la Red comenzó a funcionar sin un protocolo de sincronización de tiempo hasta que alguien se dio cuenta que esa instancia era necesaria y esa contribución hizo que Internet funcionara como lo conocemos hoy. En definitiva, lo interesante es que siempre hay alguien que -cuando se necesita- levanta la mano y realiza su aporte, en este caso, el de David L. Mills.

Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.