La innovación en Internet, una historia de adaptación constante y soluciones a medida

05/06/2024

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

Existe un interesante punto en cómo se ha gestado la innovación y la evolución de Internet a lo largo de su historia que difiere sustancialmente de lo que ha ocurrido en otros casos: en Internet se han ido inventando las soluciones a medida que hicieron falta, a diferencia por ejemplo de cómo trabajan otras disciplinas de diseño o de cómo se han construido otras tecnologías -como las redes telefónicas- donde el paradigma predominante es “de arriba hacia abajo” y las especificaciones o marcos generales son los que determinan las funcionalidades, los recorridos o los entornos que se van a utilizar.

En este sentido, me gustaría tomar el caso de la arquitectura más famosa de las redes de computadoras: el modelo de “siete capas” o “Modelo OSI”  (Interconexión de Sistemas Abiertos, por sus siglas en inglés). A fines de los años 70s, ya se empezaba a advertir que las computadoras necesitaban interconectarse. En ese momento, lo único que existía eran los mecanismos propietarios definidos por  los grandes fabricantes de las micro y de las mini computadoras (por ejemplo los entornos de IBM, entre otros). Lo importante a destacar es que cada fabricante tenía su estándar de comunicación entre computadoras.

Progresivamente la discusión empezó a girar en torno a la sostenibilidad de dicho modelo, que ni siquiera era funcional para los propios fabricantes. Emergía la necesidad de definir una estructura estándar de redes y el resultado fue la definición del modelo OSI. Para entonces, los fabricantes más tradicionales recurrieron a un organismo de estandarización (International Organization for Standardization) y partieron de una serie de requerimientos base. Desde allí fueron hacia abajo y definieron un variedad de instancias y parámetros para el funcionamiento del modelo (de hecho, el documento completo constaba de unas 2000 páginas)

Lo más interesante que derivó de ese modelo fue el concepto de “capa”: si los datos entre dos dispositivos viajan por alguna forma de medio físico (conexión eléctrica) ¿cómo esas señales se convierten efectivamente en una página de Internet?. La respuesta es que van recorriendo una serie de capas y cada una de esas capas va sumando una funcionalidad. La capa física (responsable de los equipos físicos y la que posibilita la transferencia de datos, como cables y routers y donde los datos se convierten en un flujo de bits). Luego la capa de enlace de datos (responsable de la transferencia de información en la misma red y del control de los errores y el flujo de datos) y la capa de red (encargada de dividir los datos en el dispositivo del remitente y de recomponerlos en el dispositivo del destinatario cuando la transmisión ocurre entre dos redes diferentes). El modelo se completa con la capa de transporte, la capa de sesión, la capa de presentación y la de aplicación.

Si bien conceptualmente el modelo OSI es muy relevante, lo que ocurrió con su implementación concreta tiene más que ver con algo del orden de lo práctico: les llevó muchísimo tiempo escribir y definir todos los parámetros, pero una vez que el stack estuvo completo y todas las definiciones estuvieron listas, ya todo el mundo utilizaba el protocolo TCP/IP.

Me interesa destacar que OSI fue más allá e incluso definió protocolos de enlace y protocolos de red, sin embargo, si bien se invirtió mucho tiempo y dinero en definir esos protocolos, no se utilizan por más que funcionen correctamente.  El único que tiene cierta utilidad entre los usuarios -los puristas suelen decir que se utiliza en redes de telefonía- es el protocolo IS-IS, un protocolo de puerta de enlace interior (IGP) que utiliza información de estado de vínculo para tomar decisiones de enrutamiento.

¿Qué quiero decir con todo esto? Que a veces lo perfecto es enemigo de lo bueno.  ¿TCP/IP es el mejor protocolo que existe? Definitivamente no, tiene problemas y contras, pero lo cierto es que estuvo disponible cuando la gente lo precisó. Imaginemos en los tiempos de entonces -cuando emergió la necesidad de interconexión entre computadoras- que la solución era urgente, no podía esperar a que un estándar estuviera listo. Si yo necesito conectar 20 ministerios o 20 oficinas o las computadoras de una universidad, es mi necesidad la que marca el ritmo.

Otro ejemplo que ilustra este punto es que a mediados de los 90s, cuando el IETF se dio cuenta que el IPv4 no era sostenible, organizó una suerte de concurso de ideas de cómo debería evolucionar IPV4. Una de las propuestas era utilizar ConnectionLess Network Protocol (CLNP), un protocolo utilizado por OSI para transportar datos e indicación de errores en el nivel de red. En su funcionamiento es muy parecido al IP pero aloja direcciones más grandes, de manera que permitía resolver esa coyuntura. Sin embargo, lo que ocurrió es que si bien existía algo de experiencia de trabajo con ese protocolo, prácticamente no existían implementaciones.

Además, en la cuestión de CLNP influyó definitivamente la ausencia de un estándar abierto. La existencia de procesos abiertos es fundamental en toda la historia de innovación de Internet. A diferencia de los entornos cerrados y definidos, los abiertos permiten que mucha más gente participe en las decisiones, está disponible gratuitamente para su adopción, implementación y actualizaciones. Las empresas dentro de una industria comparten estándares abiertos porque aportan gran valor a ellas mismas y a sus clientes. Las normas suelen ser gestionadas conjuntamente por una base de partes interesadas. Por lo general, existen reglas sobre qué tipo de ajustes o actualizaciones pueden realizar los usuarios para garantizar que el estándar mantenga la interoperabilidad y la calidad.

Todo esto es moneda corriente en el marco de las reuniones del IETF, quien publica su documentación técnica como RFC (“Solicitudes de comentarios” por sus siglas en inglés) donde se definen los fundamentos técnicos de Internet, como las tecnologías de direccionamiento, enrutamiento y transporte. Los RFC –que muchas veces conllevan erratas por su carácter de proceso abierto– recomiendan las mejores prácticas operativas y especifican protocolos de aplicación.

Volviendo al punto central,  cuando todo comenzó allá por 1969, el stack de OSI tenía toda una serie de funcionalidades pensadas, especificadas y detalladas, sin embargo, quien envió el primer paquete de datos por Internet necesitaba solamente eso, no mucho más. Con el tiempo, a medida que la necesidad de interconexión fue avanzando y evolucionando, se fueron inventando las soluciones a medida. Esto ha quedado registrado en diversos RFC, como el correspondiente al primer protocolo de enrutamiento de Internet de 1988 (que emergió de una necesidad puntual de  intercambiar rutas información entre puertas de enlace y que luego decidieron documentar)

En IP tenemos la discusión de que las cosas son “best effort”. Por ejemplo: mi computadora manda un paquete de datos y no tiene ninguna certeza de que ese paquete va a llegar a destino, básicamente funciona porque las leyes de la estadística juegan a favor: para que lleguen 100 paquetes es necesario transmitir 110. Lo importante aquí es que el modelo funciona bien y funciona de una manera económica, que es una de las cosas que lo distinguen del resto de los protocolos. Destaco asimismo que el stack OSI también es un modelo de paquetes y no de circuitos, pero tiene mucha capa de control, que suma complejidad para el usuario.

En contraposición por ejemplo a lo que ocurrió con OSI, la cuestión central aquí es la ventana de oportunidad: las personas necesitan las cosas en el momento preciso que las necesitan y eso fue lo caracterizó y marcó la actividad de los pioneros de Internet, quienes iban inventando las soluciones en respuesta a requerimientos puntuales. Lejos de los condicionamientos de “arriba hacia abajo” la innovación que marcó a Internet fue mucho más adaptativa que estandarizada y en definitiva, fue eso lo que hizo que el modelo fuera mucho más ágil y exitoso.

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