Tags: linux, picotux, ethernet, uets, tcp-ip

Me pasa mi amigo Pas la dirección a la página de picotux, un servidor web que tiene prácticamente el tamaño de un conector RJ-45, y que lleva embebido un kernel Linux 2.4.27.

Es curioso que cuando alguien se plantea prescindir de lo superfluo al diseñar un ordenador no prescinda de Ethernet, de hecho, ¡casi ocupa tanto espacio la etiqueta que indica la dirección MAC que la propia máquina!

No se si se han dado cuenta, pero Ethernet es la red universal desde hace mucho tiempo. TCP/IP se está convirtiendo gradualmente en un nivel de abstracción, casi en una ficción, que permite pedir servicios a la red subyacente, que siempre es Ethernet. Los "cores" de las redes de las operadoras hace tiempo que no son un conjunto de routers de nivel 3 que encaminen paquetes, sino un conjunto de switches que conmutan tramas de nivel 2. El problema es que aún conmutan usando el clásico algoritmo transparent bridging, que se basa en tablas en memoria, pero cuando se dé el paso definitivo hacia una ethernet de direcciones jerárquicas y las tramas de nivel 2 puedan viajar por sí mismas de un lado a otro del planeta sin depender de un routing de nivel 3, TCP/IP habrá muerto definitivamente como protocolo de red de nivel 3/4 y se habrá convertido en lo que es su sitio natural en la actualidad, en un API de servicios de red para aplicaciones.

En este escenario que acabo de describir, un usuario pediría un servicio al API de TCP/IP, por ejemplo, una página web, y dicha petición se materializaría en un paquete que se encapsularía en una trama Ethernet que viajaría al destino mediante switching y que sería interpretada en destino mediante eliminar los cabeceros de nivel 2 para que vuelva a aparecer la petición al servicio web que estaría, como es natural, en el socket con puerta 80 de la máquina destino. El funcionamiento, por tanto, sería el mismo que actualmente, con la diferencia de que TCP no habría hecho ningún control de integridad del paquete ni ninguna retransmisión caso de ser necesaria, e IP no habría hecho ningún trabajo de encaminamiento. Dado que hemos eliminado todo ese trabajo innecesario, la trama se habría podido desplazar por la red a la velocidad que marque el medio físico, y no a la velocidad que impone el control por software que actualmente estrangula los anchos de banda.

Las consecuencias de mantener actualmente a TCP/IP como protocolo de comunicaciones es que el rendimiento de las máquinas no escala tanto como el ancho de banda que Ethernet les hace disponibles. Pronto tendremos Ethernet a 100 Gbps y TCP/IP sigue sin poder subir de un rendimiento de 1Gbps, o lo hace a costa de múltiples CPUs y de más consumo energético, algo ilógico cuando se piensa que lo mismo se hace con mucha más eficacia y economía por hardware.

Cito literalmente del la revista IEEE Computer de Noviembre de 2004:

Our recent measurements on state-of-the-art platforms show that TCP/IP 
processing of application data (a full frame payload size of 1,460 bytes) 
consumes one entire current generation CPU to achieve roughly 750 Mbps of 
throughput while receiving data and around 1 Gbps of throughput while 
transmitting data. Clearly, it currently is not possible to achieve a 
tenfold increase in TCP/IP throughput. 

The major impediment to achieving 10-Gbps throughput is that CPU and 
memory speeds are not expected to improve as dramatically as Ethernet 
technologies.

El gran coste que tiene evaluar una ruta IP por software con las tablas de enrutamiento en comparación con el mínimo coste de evaluar una ruta por hardware que es posible hacer en una Ethernet que use direcciones jerárquicas, sumado al hecho de que comprobar la integridad de un paquete TCP con checksum es muchísimo más costoso que hacer un CRC por hardware de una trama Ethernet debería de ser un argumento más que convincente para plantearse en serio la transformación de TCP/IP en un API.

No mucha gente se lo plantea, pero ya hace tiempo que no se comprende que TCP/IP siga siendo un protocolo de comunicaciones, con sus controles de errores y restransisiones, en lugar de convertirse en lo que NetBIOS fue para NetBEUI, un nivel de abstracción que pide servicios a un protocolo de red subyacente, y así dejar que sea Ethernet quien haga la verificación de la integridad de los datos, e incluso los servicios de circuito virtual permanente que hace TCP en la actualidad. Desgraciadamente hay tan poco conocimiento sobre Ethernet que casi nadie (excepto el Ethernet Forum liderado por José Morales) se ha dado cuenta de que Ethernet debería de ser el protocolo de red y TCP/IP está ya en un lugar donde estorba más de lo que ayuda.

Y otro problema más: en los "cores" de la red que manejan las operadoras ya estamos llegando al punto en el que las tablas de switching que tienen los conmutadores son un lastre, porque el tiempo de acceso a la memoria para consultar por dónde soltar una trama es demasiado grande en comparación con el tiempo que el conmutador tiene para despachar la trama, que es cada vez mayor al aumentar la velocidad del medio físico.

Cualdo alguien escucha esto por primera vez suele comentar: "pero si no se puede enrutar Ethernet, porque es un protocolo que solo sirve para redes de área local, ¿cómo vamos a poder sustituirlo con TCP/IP, que está diseñado específicamente para ser enrutado e interconectar equipos separados por routers?".

Pues aquí es donde entra UETS, la red Ethernet de direcciones jerárquicas, conmutable por hardware, sin tablas en memoria. Pero de esto ya escribiré otro día.