La respuesta obvia a las redes tolerantes a demoras es almacenar y reenviar.

Con TCP, cuando un enrutador recibe un paquete, inmediatamente lo envía al siguiente salto o, si no puede, lo rechaza y devuelve un error.

Con un protocolo de almacenamiento y reenvío, cuando un enrutador recibe un paquete, busca la próxima vez que espera poder hablar con el siguiente salto (posiblemente eligiendo entre múltiples posibilidades según el tamaño del paquete, cuál es su las etiquetas QoS dicen, etc.) y lo almacena hasta entonces.

Store-and-forward se remonta a SMTP, NNTP, UUCP y otros protocolos anteriores a la Internet pública. Antes de 1994, si su empresa quería tener correo electrónico externo, eso generalmente significaba que su servidor se conectaba a su proveedor dos veces al día a través de UUCP y enviaba y recibía todos los mensajes salientes y entrantes. Pero los DTN modernos necesitan algo más granular que "enviar todo a un host dos veces al día". (Además, estos protocolos están diseñados para redes que se conectan con poca frecuencia pero de baja latencia mientras están conectadas, por lo que hacen un protocolo de enlace mucho más ruidoso de lo que desea para las redes que se conectan a menudo pero de alta latencia).

Mientras tanto, almacenar y reenviar a nivel de pequeños paquetes IP no es tan útil, por lo que agrega una forma para que las aplicaciones definan paquetes de múltiples paquetes. Luego puede enrutar, QoS y administrar la congestión de paquetes completos (así que, idealmente, cuando envía accidentalmente a casa un video 4K en lugar de uno SD, se agota el tiempo de espera en su enrutador local en lugar de desperdiciar todo su ancho de banda y la mitad de su ISP). antes de caer). Como beneficio adicional, los paquetes pueden ser lo suficientemente grandes como para permitirse funciones de seguridad como el enrutamiento basado en la identidad, que también puede ser importante para una DTN.

La forma obvia de hacer todo esto es definir una red de superposición de enrutamiento sobre UDP, muy similar a la forma en que las mallas P2P (posteriores a BitTorrent) funcionan como una superposición sobre UDP. (Excepto que, a diferencia de una malla P2P típica, necesita algo de inteligencia para que no solo vuelva a intentar los paquetes UDP con retroceso exponencial y ajuste de malla automático, sino que almacene horarios programables en su tabla de enrutamiento, porque muchas cosas serán predecibles —no rebotes en ese satélite lunar durante las próximas 3 horas porque está bloqueado por la luna…)

La última vez que miré esto fue hace aproximadamente una década, y el estado del arte era el protocolo experimental en RFC 5050 . Probablemente ha habido avances desde entonces, y es posible que no esté recordando todo a la perfección.

La NASA ya pensó un poco en esto y ha desarrollado un concepto llamado "DTN" o Delay-Tolerant-Networking . Básicamente, comprueba si la conexión es posible con el siguiente "salto" o estación, y luego envía los datos. Si no está disponible, lo almacena en la memoria local hasta que se restablece la conexión. Esto puede operar junto o por separado del tradicional TCP/IP

En términos de infraestructura, estoy imaginando una solución a gran escala que involucre una serie de grandes platos espaciados alrededor del planeta para que al menos uno siempre tenga una conexión con un lugar o planeta determinado. Estos platos actúan como puentes hacia el resto del sistema solar, emitiendo enormes cantidades de datos a sus destinatarios a medida que las conexiones están disponibles. Al conectarlos en red, pueden transferirlo automáticamente de un plato al siguiente según sea necesario.

Probablemente desee cambiar de TCP/IP, que se basa en paquetes, a algo que sea direccionable por contenido. TCP/IP se basa en la suposición de que puede señalar la congestión a las personas que usan la red descartando paquetes. Si su tiempo de ida y vuelta es alto, se convierte en un método de señalización muy costoso.

Lo que le gustaría hacer es decirle a la red que desea cierta información y descargarla del nodo más cercano que tenga esa información. De esa manera, puede obtener su información más rápido si alguien más ya usó esa información antes. Un ejemplo de una implementación actual de esto es IPFS (Sistema de archivos interplanetarios).

Funciona como un gigantesco enjambre de bittorrent en el sentido de que descarga la información necesaria de pares cercanos que tienen la información. Esto reduce el tráfico duplicado en enlaces congestionados/costosos y disminuye la cantidad de tiempo que lleva obtener la información que necesita.

¿Cuál es el conjunto de cambios más pequeño que puede realizar en el conjunto de protocolos TCP/IP para optimizar su rendimiento en las redes interplanetarias?

Estoy un poco sorprendido de que nadie haya dicho esto todavía, pero no usaría ni TCP ni UDP. No es viable. La idea de cualquier nivel de conexión en vivo más allá de la órbita terrestre no es razonable. El viaje de ida y vuelta a la Luna es de 2,6 s. Aquí tenemos una conexión a Internet por cable que se vuelve bastante poco fiable cuando hace mal tiempo, por lo que he experimentado velocidades de Internet en las que los paquetes ICMP han requerido más de 2 segundos para un viaje de ida y vuelta y puedo decirles que Internet es prácticamente inutilizable bajo esas condiciones.

El mejor viaje de ida y vuelta que puede esperar entre Marte o Mercurio 6m24s y 6m, respectivamente. El siguiente lugar más interesante para estar más allá de Marte es Júpiter, y su mejor tiempo de ida y vuelta es más de una hora (69m47s).

Se mencionó la red tolerante a interrupciones/retrasos. DTN puede ser adecuado para conexiones de red en vivo orbitales o posiblemente incluso Tierra-Lunar, pero más allá de eso, usaría algo más.

Las conexiones de redes interplanetarias no estarían activas. De hecho, no tendría una conexión persistente, y mucho menos una conexión directa a cualquier Internet planetario más allá del suyo. Enviaría un paquete solicitando información muy específica y recibiría su transmisión de respuesta unos minutos o más después, dentro de los límites de tener que compartir el espectro de radio con todos los demás en el sistema solar. La transmisión se dividiría en "paquetes", pero no en paquetes en el sentido de TCP, más bien como paquetes en el antiguo sentido de Fidonet. En lugar de volver a solicitar los datos, simplemente repetiría su solicitud, especificando solo los bloques de datos que se perdieron o se confundieron; los protocolos se diseñarían de tal manera que tuvieran un marco predecible de los datos solo para que pudiera solicitar solo los datos incorrectos.

Algunos datos se transmitirían continuamente, algunos estarían disponibles a través de un transpondedor y otros se transmitirían en algún tipo de horario.

Habría alguna sincronización localizada, aunque no todo Internet. Wikipedia y otras grandes bases de datos, por ejemplo, se sincronizarían localmente. Las actualizaciones se solicitarán a partir de una marca de tiempo específica para que solo se transmitan los datos de sincronización actuales.

La comunicación en la red interplanetaria se parecería más al antiguo sistema de teletipo que al antiguo sistema BBS.

@Hobbamok me recuerda que la transmisión de microondas se usaría para las conexiones punto a punto entre los asentamientos, los puestos de avanzada y la Tierra. Es muy posible que también se utilice láser cuando sea apropiado. Eso anularía el problema de tener que compartir ancho de banda con el resto del sistema solar.

El conjunto más pequeño de cambios que podría hacer sería cambiar de TCP/IP a UDP/IP. El mayor problema con TCP es que necesita volver a consultar con el remitente para asegurarse de que el paquete haya llegado. Si toma 10 horas de ida, tomará 20 horas saber que el mensaje que envió ha llegado y si necesita reenviar paquetes.

Con UDP, este paso de verificación se ignora. Si quiero enviar un mensaje, puedo enviarlo en una fracción de segundo. Si no lo logra, la persona que solicita los datos simplemente los volverá a solicitar. No necesito mantener una conexión durante 20 horas impares, solo para asegurarme de que el mensaje ha llegado.

También necesitaría autenticar y cifrar sus datos con una clave compartida que deberá determinarse de antemano, similar a una clave SSH porque sería demasiado ineficiente cifrar las cosas dinámicamente.

Agregado -Editar: la pregunta solicita confiabilidad, rendimiento y baja latencia. Simplemente no puedes tenerlos todos. Si desea confiabilidad y alto rendimiento, no obtendrá baja latencia y si desea alto rendimiento y baja latencia, no será confiable. Es la cosita del triángulo donde solo puedes maximizar dos de los tres. Si se supone que su capa física funciona bien, entonces usar UDP y empujar el resto de la lógica a la capa de aplicación le proporcionará mejores resultados. La falta de protocolo de enlace y verificación significa que tendrá la latencia más baja posible, y el rendimiento y la confiabilidad terminarán dependiendo de su hardware.

La verdad del asunto es que no se utilizará ningún protocolo. Los protocolos garantizan diferentes cosas y sirven para diferentes propósitos. Si tiene una base/sonda remota que tarda 10 horas en comunicarse, no querrá esperar más de 20 horas para ver la transmisión de video en vivo (el apretón de manos, la transferencia de paquetes y la garantía de pedido consumirán todo su tiempo). Vas a usar UDP para asegurarte de tener el video lo más rápido posible (10 horas). Del mismo modo, si está transmitiendo un archivo, desea confiabilidad, y esto se puede agregar a nivel de protocolo (hay muchas variaciones de UDP o simplemente TCP) o nivel de aplicación. Finalmente, si desea transmitir grandes cantidades de datos, desea entregarlos físicamente,

almacenamiento en caché

La descarga en primera persona del nuevo Juego de Tronos tarda 20 horas. Después de eso, una copia se almacena en el servidor de almacenamiento en caché y solo toma unos segundos para la segunda persona.

El almacenamiento en caché mantiene los resultados de las solicitudes localmente, por lo que es lento la primera vez mientras obtiene la información, pero mucho más rápido porque ya la tiene para futuras solicitudes. El servidor solo contiene X cantidad de datos, por lo que las solicitudes más antiguas se retiran al final de la cola a medida que se llena.

El resultado final es que las solicitudes más comunes se almacenan localmente y son mucho más rápidas y la transmisión de datos es mucho menor.

Necesita cambiar la forma en que su arquitectura de Internet está configurada para tener el almacenamiento en caché de sitios web completos

No hay razón para molestarse con tiempos de inactividad prolongados en Internet, excepto en forma de mensajes enviados de planeta a planeta. Si Internet tiene un tiempo de inactividad de 20 horas solo para cargar una lista de páginas web y otras 20 horas para cargar una página, la gente simplemente no lo hará.

Si desea que las personas usen Internet, cada colonia necesita sus propios servidores para almacenar los contenidos de la web que desean poder ver. Cuando un colono se conecta, en realidad solo se está comunicando con el servidor local. Los servidores locales se comunican a través de la red satelital enviando actualizaciones a otras colonias que descargan las actualizaciones. De esta manera, navegar por la web toma segundos, aunque las noticias pueden tener unas horas de antigüedad, lo que no se puede evitar de todos modos. Este proceso de actualización significa que la red está descentralizada y, debido a que las computadoras locales no se comunican directamente con el acceso a Internet, el tráfico se reduce significativamente. Si las computadoras se comunican directamente con Internet, los enrutadores no podrán manejar todo el tráfico, especialmente si están almacenando paquetes durante el tiempo de inactividad.

Cuando los servidores se comunican, todos los paquetes se envían a la vez y la conexión no se mantiene activa. Este protocolo funciona con la idea de almacenamiento de paquetes propuesta por otras respuestas.

Si tiene varias rutas de enrutamiento a través de las cuales se pueden enviar los mensajes, cada enrutador en la ruta envía los paquetes a través de todas las rutas disponibles y la computadora receptora toma la primera que recibe e ignora los duplicados. Si el paquete está dañado, espera a que llegue un duplicado. Si después de un par de horas solo ha recibido paquetes dañados o no ha llegado ningún paquete, vuelve a solicitar los paquetes.

Los mensajes pueden usar un protocolo diferente. Los mensajes se envían desde el servidor de una colonia directamente al servidor de destino, no a ningún otro servidor de la red. Cuando el servidor receptor recibe el mensaje, envía el mensaje a la computadora que lo recibe.

Con estos métodos, los servidores no pueden permitirse el lujo de abrir y cerrar puertos. Siempre tienen que estar atentos a las actualizaciones para no perderse nada.

Beneficios de este diseño:

Menos computadoras que envían paquetes a través de los enrutadores interplanetarios, reduce drásticamente los viajes de ida y vuelta, el servidor siempre recibe el mensaje lo más rápido posible, no es necesario un apretón de manos, múltiples rutas de enrutamiento significan que la red puede soportar la pérdida de algunos satélites, comunicación casi instantánea con el servidor local , capacidad de enviar actualizaciones en lugar de que el cliente las solicite, protocolo de mensajería separado (ninguna otra colonia ve su mensaje a una colonia diferente).

Banda ancha

No ha especificado cuánto ancho de banda tiene.

Puede transmitir absolutamente toneladas de información adicional si tiene ancho de banda adicional. Por ejemplo, interplanetary netflix puede transmitir 15 minutos de las 30 películas más similares junto con la película que está viendo cuando llega a su fin, de modo que puede seleccionar otra película para ver y comenzar a verla de inmediato. Lo mismo puede aplicarse a todo tipo de datos.

Predicción

Puede agregar predicción a esto, al igual que funciona Chrome, para seguir los enlaces probables para acelerar la carga en caso de que el usuario haga clic en ellos. Tendría que agregar todos estos datos al paquete. En lugar de cargar la página de inicio de wikipedia, una solicitud a wikipedia podría predecir lo que es probable que vea y transmitir todo el sitio o un resumen de cada página.

voladura de datos

También podría hacer algo similar a una explosión de datos de los años 90, donde la información se mostraría a alta velocidad y el público la grabaría en video y la reproduciría en cámara lenta para leerla. Estar constantemente transmitiendo todo tipo de información de forma continua y almacenándola en caché, en caso de que sea necesario. Incluso con un ancho de banda bajo, cualquier 'ciclo' de repuesto podría usarse para incluir información adicional.

Ejecutabilidad remota

La ejecutabilidad remota sería la capacidad de enviar un pequeño programa que se puede ejecutar en la tierra.

Por ejemplo, quieres jugar al ajedrez interestelar con alguien en la luna Io de Júpiter. En lugar de enviar un movimiento, solo para descubrir 45 minutos después que era un movimiento ilegal porque olvidó que estaba en jaque, sería más rápido si se cargara y ejecutara un pequeño programa de ajedrez tanto en la Tierra como en Io. Luego, cuando se realiza un movimiento ilegal, se puede validar o modificar sin necesidad de enviarlo.

Esto es similar a la validación del lado del cliente en Javascript, por lo que intenta enviar un formulario para registrarse en algo y olvida completar su dirección de correo electrónico, le pedirá que lo complete antes de enviar el formulario en lugar de enviarlo y obtener un error de vuelta.

Otro ejemplo de esto es si un cliente solicita información sobre la posición de la tierra en una fecha determinada. En lugar de que envíen la solicitud y 45 minutos después reciban una respuesta, podrían recibir un pequeño programa ejecutable que calculará esto por ellos.

almacenamiento en caché

Obviamente, el almacenamiento en caché de datos para reutilizarlos localmente pero a una escala más amplia, colocando servidores en varios planetas/satélites y almacenándolos en caché en cada uno de ellos. Por ejemplo, los grandes sitios de noticias serían populares todos los días, por lo que esto se distribuiría y almacenaría en caché entre todas las ubicaciones. Otros datos también se almacenarían en caché y se mantendrían en función de las vistas. Esto es muy similar a cómo funcionaba el sistema de almacén de Amazon: los artículos que es probable que compre la gente se distribuyen automáticamente a los almacenes utilizando algoritmos que predicen que la gente comprará los artículos, lo que ahorra tiempo de envío.

Supongo que una de las cosas clave a tener en cuenta es el cambio de paradigma requerido en términos de desarrollo de Internet. No es realmente una cuestión de cómo entregamos las páginas web y la experiencia de Internet actual , es más una cuestión de cómo se vería la red mundial si la latencia fuera increíblemente alta. . Volvería a capacitar a sus ingenieros de software y reescribiría todas sus herramientas, e Internet se basaría principalmente en aplicaciones, probablemente descargaría la aplicación BBC News y la actualizaría automáticamente todas las mañanas desde un caché local, ya sea descargando todo el sitio, o simplemente navegando por todo el sitio localmente desde un caché.

IPTP (Protocolo de transmisión interplanetaria)

IPTP es un protocolo bidireccional, punto a punto, de almacenamiento y reenvío, diseñado para ser altamente tolerante a fallas.

Los enlaces IPTP se definen entre planetas de modo que en un momento dado haya exactamente un transmisor en órbita alrededor de un planeta transmitiendo datos a cualquier conjunto de receptores en el otro. (El transmisor activo cambiará a medida que el planeta gire y los satélites giren a su alrededor). Este flujo debe poder multiplexar una gran cantidad de subflujos de datos diferentes (procedentes de muchas fuentes diferentes en el Internet planetario de origen), que a su vez ponerse en cola en los búferes para la transmisión real.

El flujo general se dividirá en "bloques" de un tamaño apropiado para la calidad del enlace, cada uno de los cuales se codificará individualmente mediante la corrección de errores Reed-Solomon, y se transmitirán periódicamente bloques de "paridad" adicionales, lo que permitirá la reconstrucción de bloques que excedió el umbral de corrección de errores del código RS en uso para ese bloque. (IPTP permite cambiar el tamaño de este bloque según lo justifiquen las condiciones). Cada bloque debe retenerse en el extremo de envío hasta que se reciba un acuse de recibo de bloque (BACK) del receptor.

Para mayor solidez, después de transmitir una serie de "filas" (N bloques de datos más un bloque de paridad XOR de esos bloques de datos), se transmite una "fila de paridad" (construida mediante la combinación XOR de los bloques correspondientes en M filas consecutivas). Al final de un grupo (llamado "capítulo") de L páginas de M filas y N columnas hay una "página de paridad" (construida mediante la operación XOR de los bloques correspondientes en todas las páginas). Todo el capítulo de (L+1)(M+1)(N+1)bloques debe usar el mismo tamaño de bloque y codificación RS, pero los capítulos posteriores pueden cambiar el tamaño del bloque, así como los valores de L, M y N, según lo justifiquen las condiciones. En general, L, M y N serán mayores cuando sea necesario volver a enviar menos bloques.

Dentro de un capítulo, los subflujos deben ensamblarse en orden de prioridad para minimizar la cantidad de bloques que transportan datos de dos o más prioridades diferentes. La prioridad de transmisión de un bloque es igual al subflujo de nivel de prioridad más alto que contiene.

Antes de cada capítulo hay un encabezado que define esos parámetros. [El Grupo de trabajo de transmisión interplanetaria dice que las futuras versiones de IPTP pueden extender el sistema de paridad a "libros" de K tales capítulos, incorporando (K+1)(L+1)(M+1)(N+1)bloques cada uno. IPTPv1 define K=1 sin paridad, por lo que un libro tiene solo un capítulo.]

Los metadatos "BACK" deben enviarse de regreso del receptor al transmisor para reconocer capítulos completos, así como rangos de bloques dentro de un capítulo. Cualquier bloque no retrocedido que caiga antes del último bloque retrocedido tendrá que ser retransmitido. La determinación de retransmitir no debe tomarse hasta que se haya recibido y descifrado todo el "libro", ya que los bloques, líneas, páginas (y capítulos) de paridad para permitir la reconstrucción completa de un BACK aún no se habrán procesado. Debido a que un BACK en sí mismo ocupa uno o más bloques para ser BACKed, siempre habrá algo para BACK, creando un "keepalive" implícito entre los nodos.

Los metadatos (incluidos, entre otros, los BACK anteriores) son el nivel de prioridad más alto para las subtransmisiones y, por lo tanto, siempre deben ser lo primero en un libro/capítulo después del encabezado del protocolo. El IPTTF todavía está definiendo los detalles de otras consideraciones de QoS.

Una vez que el flujo de datos se reconstruye en el extremo receptor, se puede demultiplexar en subflujos, cada uno de los cuales se envía a su destino deseado en la Internet planetaria.

Una revisión completa es el cambio sensato más pequeño

• Con una latencia de 10 horas, seguramente no querrás establecer ninguna conexión ya que solo necesita tres paquetes, lo que significa 30 horas desperdiciadas .
• El control de congestión tipo TCP no tiene sentido. Para obtener la máxima eficiencia, desea dirigir sus platos exactamente a la persona con la que se comunica. Eso es cierto tanto para el emisor como para el receptor (habrá una configuración fija como "este plato se comunica con Plutón" o un horario preestablecido). Esto elimina cualquier congestión en el propio enlace . El enlace siempre funcionará con una velocidad fija, a menos que se rompa.
• Como el costo de transmisión es mucho más alto que el costo de almacenamiento, cada paquete enviado también se almacenará hasta que se reconozca (muchas horas después).

Supongo que UDP confiable se acerca más a lo que se necesita. De todos modos, puedes olvidarte de usar la red para navegar o similares. Se parecerá más a SMTP. Envía un mensaje y se entregará, posiblemente retrasado por muchas horas debido a las retransmisiones. Puede tener alguna comunicación cliente-servidor, pero se parecerá más a solicitar un libro de una biblioteca que a HTTP.