{"id":2037,"date":"2026-04-06T08:00:00","date_gmt":"2026-04-06T11:00:00","guid":{"rendered":"https:\/\/www.nerdadas.com\/blog\/?p=2037"},"modified":"2026-04-05T22:42:03","modified_gmt":"2026-04-06T01:42:03","slug":"dtn-comunicaciones-tolerantes-al-retardo","status":"publish","type":"post","link":"https:\/\/www.nerdadas.com\/blog\/dtn-comunicaciones-tolerantes-al-retardo\/","title":{"rendered":"DTN – Comunicaciones tolerantes al retardo"},"content":{"rendered":"\n

Con Artemis II\/Orion<\/strong> la Nasa est\u00e1 probando un nuevo sistema de comunicaciones para misiones en el espacio. (https:\/\/www.nasa.gov\/technology\/space-comms\/o2o\/<\/a>), una comunicaci\u00f3n directa pero con algunas cuestiones t\u00e9cnicas interesantes para los que trabajamos en comunicaciones a diario. <\/p>\n\n\n\n

Este nuevo sistema consta de un laser y unos sistemas de gimbals muy complejos para apuntar a la nave con qui\u00e9n van a establecer la comunicaci\u00f3n, en este caso la c\u00e1psula Orion<\/strong>, ya que el punto \u00f3ptico del laser es muy peque\u00f1o.<\/p>\n\n\n\n

La idea es bastante sencilla,un laser apuntando a un sensor con un stack de protocolos propietarios. <\/strong>Esto ya exist\u00eda pero con RFs<\/strong>, la DSN<\/a><\/strong> o CDSN<\/a><\/strong>(en el caso de china) es la Red del Espacio Profundo: Varias antenas en diferentes partes del planeta apuntando al espacio<\/strong> y emitiendo\/escuchando mensajes hacia los dispositivos al alcance.<\/p>\n\n\n\n

Pero que pasa con aquellos que est\u00e1n m\u00e1s lejos o est\u00e1n en lugares con conexiones intermitentes?. Para eso existen las Redes con Tolerancia al Retardo<\/strong> y cambia todo lo que crees que sabes en comunicaciones.<\/p>\n\n\n\n

Laboratorio para poner en contexto.<\/h2>\n\n\n\n

Para ponernos en contexto empiezo con un laboratorio sencillo. 2 Equipos linux conectados uno contra el otro. Netem y Server. Vamos a probar que sucede con los retardos en TCP\/IP<\/strong><\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Ambos debian 13. Vamos a instalar unas herramientas que seguro ya ten\u00e9s en tu equipo <\/strong>y probemos un poco que sucede con tcp\/ip en estos escenarios.<\/p>\n\n\n\n

sudo apt update && sudo apt install iperf3 iproute2\n\n#Simular ida y vuelta\n#En NETEM:\ntc qdisc add dev eth0 root netem delay 300ms\n\n#En Server:\ntc qdisc add dev eth0 root netem delay 300ms<\/code><\/pre>\n\n\n\n
con tc vamos a agregar 300ms de delay en el server y en el cliente (600ms en total) y vamos a ver que sucede.<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Perfecto, ya tenemos un delay bastante alto, 600ms.
Ahora agregamos a la configuraci\u00f3n anterior 300ms m\u00e1s del lado del servidor y obtenemos esto:<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
En el espacio, tenemos que incorporar un valor m\u00e1s que es el Jitter<\/strong>. Qu\u00e9 es el Jitter<\/strong>?. El jitter aparece cuando la latencia no es pareja, ejemplo:
paquete 1 \u2192 300 ms (latencia)
paquete 2 \u2192 350 ms
jitter = 50ms<\/p>\n\n\n\n
Ese Jitter<\/strong> pueden ser muchas cosas, un cable da\u00f1ado, una red saturada, un satelite haciendo una maniobra.<\/strong>.. ejem!.<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Funcionan los servicios con tanto retardo o jitter?. Bueno, la mayor\u00eda de las veces si, en una red normal en el planeta tierra. Ejemplo:
<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Montamos un server web con python y probamos y sip, funciona correctamente. Algo lento para ver un video de youtube pero funciona. El gran problema viene cuando el jitter y el delay se nos van de las manos.<\/p>\n\n\n\n
Medimos ancho de banda:<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Podemos ver que con la perdida configurada hay paquetes que se reenvian, se pierden y vemos el tcp \u00abestabilizandos\u00e9\u00bb a medida que la conexi\u00f3n avanza. En total 23 reenvios de paquetes.<\/p>\n\n\n\n
Que pasa con UDP que no reenvia nada cuando pierde?.<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Bueno, en UDP tenemos perdida directa. En este caso la p\u00e9rdida configurada 1.1%.<\/strong><\/p>\n\n\n\n
Qu\u00e9 pasa cuando el delay aumenta (O la nave se aleja?)<\/p>\n\n\n\n
Para simular esto configur\u00e9 tc con un delay de 10000ms en un equipo y 20000ms en el otro<\/strong> y vemos que sucede.<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Perdimos todo, vamos a tener que cambiar el timeout <\/strong>y esperar que el paquete responda:<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Enviamos 50 paquetes con hasta 50seg de espera y obtenemos respuesta. Con un peque\u00f1o retardo de 30 segundos entre ping… pero funciona!!!<\/strong><\/p>\n\n\n\n
Hasta ahora todos caso con retardos \u00abmanejables\u00bb. Aumentamos el timeout, esperamos y solucionado momentamente el problema pero que pasa cuando no sabemos de cu\u00e1nto ser\u00e1 el timeout?. Ahora si estamos en contexto.<\/strong><\/p>\n\n\n\n
DTN – Delay\/Disruption Tolerance Network<\/h2>\n\n\n\n
Es importante que sepas que, a partir de ac\u00e1, todo lo que sabes de TCP\/IP se vuelve irrelevante. Esta explicaci\u00f3n va muy por encima pero tratar\u00e9 de ser \u00abentendible\u00bb.<\/strong><\/p>\n\n\n\n
En redes normales el flujo de datos tiene el siguiente formato: A \u2500\u2500\u2500 B \u2500\u2500\u2500 C \u2500\u2500\u2500 D. 
Se dice que son End to End<\/strong>. A <\/strong>quiere hablar conB <\/strong>as\u00ed que solo le habla y B <\/strong>escucha y responde y as\u00ed secuencialmente. Sabemos con claridad cu\u00e1l es el camino.<\/p>\n\n\n\n
En las redes DTN<\/strong>: A B C y D pueden no estar disponibles cuando envio el mensaje, por lo tanto no hay camino completo al mismo tiempo. Ac\u00e1 es donde muere TCP\/IP. <\/strong>
TCP\/IP est\u00e1 orientado a la conexi\u00f3n y en este caso cuando se env\u00eda un mensaje probablemente no haya conexi\u00f3n(quiz\u00e1s el satelite est\u00e9 cruzando Marte por detr\u00e1s).<\/strong><\/p>\n\n\n\n
Ac\u00e1 entra el concepto Store<\/strong> – Carry<\/strong> – Forward<\/strong>. El flujo de las DTN, con este concepto, ser\u00eda algo as\u00ed:<\/p>\n\n\n\n
[ A ] --mensaje--> (lo guarda, Store)\n   \u2193 se mueve\n[ A ] ----> encuentra [B] ----> le pasa copia\n                    \u2193\n                  [B] se mueve(carry) y entra en alcance de [C]\n                    \u2193\n                 (forward)Mensaje llega a [C]<\/code><\/pre>\n\n\n\n
Historia ejemplo<\/strong><\/h2>\n\n\n\n
Es como llevar el mensaje \u00abpor casualidad\u00bb<\/strong>. A conoce a B, es su vecino<\/strong>, le da un mensaje para D <\/strong>y le dice: \u00absi encontras a alguien que lo vea dasel\u00f3\u00bb. B sigue su vida hasta que camino a su trabajo se encuentra con C<\/strong>, yendo a su trabajo tambi\u00e9n. B le entrega el mensaje de A a C<\/strong> y C al llegar a su trabajo, si D a ido a trabajar ese d\u00eda, le entrega el mensaje<\/strong>, sino se lo entregar\u00e1 ma\u00f1ana, se lo guardar\u00e1 para que llegue el momento.<\/p>\n\n\n\n
Algoritmos<\/h2>\n\n\n\n
En DTNs<\/strong> los paquetes (lo que en TCP\/IP conocemos como PDU) se llaman Bundles<\/strong>. La estructura normal de un bundle es algo as\u00ed:<\/p>\n\n\n\n
+----------------------+\n| Bundle               |\n|----------------------|\n| Source              |\n| Destination         |\n| Payload             |\n| TTL \/ metadata      |\n+----------------------+<\/code><\/pre>\n\n\n\n
Como te habr\u00e1s dado cuenta un \u00abnodo\u00bb dentro de esta red de comunicaciones puede en alg\u00fan momento de su vida tener un mont\u00f3n de bundles<\/strong> para entregar. Cada emisi\u00f3n es energ\u00eda que usa y cada bundle no entregado es espacio almacenado<\/strong>. Al hablar de sistemas de comunicaci\u00f3n en el espacio la optimizaci\u00f3n se vuelve cr\u00edtica. Es ah\u00ed donde los matem\u00e1ticos se pusieron creativos y hay un mont\u00f3n de papers con algoritmos muy interesantes para cada caso de an\u00e1lisis. Ac\u00e1 solo voy a contarte los que encontr\u00e9 se usan actualmente.<\/p>\n\n\n\n
Todos los algoritmos existentes caen en 4 categor\u00edas:<\/p>\n\n\n\n
    \n
  1. Flooding (inundaci\u00f3n)<\/li>\n\n\n\n
  2. Replicaci\u00f3n controlada<\/li>\n\n\n\n
  3. Probabil\u00edsticos \/ hist\u00f3ricos<\/li>\n\n\n\n
  4. Basados en contexto<\/li>\n<\/ol>\n\n\n\n
    Cada uno tiene un enfoque distinto pero todos tratan de ser coherentes con el rendimiento de equipos con bajos recursos y, obviamente, la seguridad en la entrega. Todo lo que sigue es un tanto copy & paste con comentarios mios de estudio, pero muy interesante!.<\/strong><\/p>\n\n\n\n
    * Algoritmos de inundaci\u00f3n<\/h3>\n\n\n\n
    Epidemic Routing<\/h4>\n\n\n\n
    El ruteo epid\u00e9mico es el enfoque m\u00e1s simple y sirve como base conceptual para otros algoritmos. Consiste en replicar cada mensaje en todos los nodos con los que se establece contacto.<\/p>\n\n\n\n
    Ventajas:<\/p>\n\n\n\n