EVALUACIÓN DEL DESEMPEÑO

Hemos llevado a cabo extensos experimentos de simulación para investigar la actuación

de RCP-Planet.
¿Cómo elegir el adecuado sondeo de tamaño de secuencia L se discute en la Sección
5.2. La tasa de fuente de envío de se ilustra en la Sección 5.3. Rendimiento de RCP-
Planet es analizado junto con sobrecarga, FEC tasa de recuperación del bloque, y la
equidad en las secciones 5.4 a 5.7 respectivamente. Ancho de banda de asimetría se
discute en la Sección 5.8. Por último, el apagón desempeño se analiza en la Sección 5.9

5.1. Escenario de simulación

El escenario de simulación se muestra en la Figura 16. N remitentes RCP-Planet en
Marte transmiten datos a N receptores en la Tierra. Los datos se transmiten en primer
lugar de entrada B en la superficie de Marte a la Orbitador de Marte, a continuación, a
través del enlace de backbone interplanetario a la Tierra por satélite y, finalmente, llega
a la puerta de entrada A en la superficie de la Tierra. El mensaje se transmite
información sobre los enlaces inversos. Los flujos de datos N son multiplexadas en una
pasarela en la superficie de Marte y del flujo inverso de datos de gateway B en la
superficie de la Tierra. Los segmentos en los canales directo e inverso pueden perderse
debido a errores de enlace con una probabilidad ploss pérdida. Si no se especifica, se
supone N = 10, el tamaño de búfer de puerta de enlace es 200 paquetes. También
suponemos que la capacidad del enlace es c ¼ 1.300 paquetes / s, que es
aproximadamente de 10 Mb/s para un paquete de datos de tamaño de 1 KB. La tasa
objetivo se supone que es 140 kB / s menos que se indique lo contrario

5.2. Número de paquete NIL

Cambio-sondeo mecanismo que se utiliza para capturar ancho de banda disponible en
RCP-Planet, el número de paquete NIL L debe elegirse adecuadamente para captar la
disposición de ancho de banda lo más preciso y rápido como sea posible y reducir sus
gastos generales.
Para investigar la forma en L afecta a la sobrecarga y el rendimiento, sólo una conexión
se utiliza para eliminar otros efectos sobre el mismo de otras conexiones. Suponemos
RTT =300, 600, y 900 s, respectivamente. Tasa de pérdida de paquetes debido a errores
de enlace ploss= 10-4, y el tiempo de simulación es de 3600 s.
La sobrecarga correspondiente a L se muestra en la Figura 17.
La sobrecarga para diferentes valores de RTT es casi la misma. Con el aumento de L de
1 a 20; la sobrecarga aumenta de 0:085 a 0:234: Obviamente, a mayor L conducirán a
una mayor sobrecarga.
 Fig 17. Overhead vs NIL paquete número L

Fig 18.Rendimiento vs NIL paquete número L

El rendimiento se define como el número de paquetes de datos que se recuperó con

éxito de la bloques FEC divididos por el tiempo de ejecución. El rendimiento para
diferentes valores de RTT se muestra en la Figura 18.
Cuando L es pequeño, el rendimiento es bajo. Por ejemplo, cuando RTT = 600 y L = 1;
el rendimiento es de sólo 85,76 kbps. Esto se debe a pequeña L no puede capturar el
ancho de banda disponible.
El rendimiento aumenta con el aumento L: Pero cuando L llega a 14, el grado de
rendimiento incremento es muy pequeña. Cuando RTT = 300, el aumento de
rendimiento es de sólo 0,18 kbps de L = 14 a L = 20; pero la sobre carga aumenta de 19
a 23:03%:
La tasa de recuperación FEC Rblk es el porcentaje de bloques de FEC que se recuperó
con éxito y que se define como

donde Nr es el número de bloques FEC se recuperó con éxito y Nt es el número total

recibido de bloques FEC. Si un bloque FEC no puede ser recuperado con éxito, los
paquetes originales perdidos no puede ser reconstruida y, por tanto, dar lugar a la
degradación del rendimiento de procesamiento.
Después de la FEC bloque de longitud n se calcula a partir de la actual tasa de pérdida
de p paquete por la Ecuación (4) como se discute en la Sección 3.1, que
conservadoramente añadimos L paquetes redundantes adicionales para recuperar los
perdidos sondeo de paquetes. Como resultado, la RCP-Planet intenta obtener la
mayor Rblk como sea posible. Cuando L aumenta, el número de paquetes redundantes
adicionales también aumenta, por lo tanto, la tasa de recuperación de bloque FEC
también se incrementa.
Para lograr un buen rendimiento, la secuencia de sondeo longitud L debe elegirse
adecuadamente tal que RCP-Planet tiene una alta tasa FEC bloque de recuperación, de
alto rendimiento y bajo costo operativo.
Teniendo en cuenta estos factores, elegimos L = 14 paquetes para todas las simulaciones
posteriores

5.3. La tasa sondeado y la tasa de fuente-envío

Para mostrar el comportamiento de la tasa sondeado ra y la tasa de fuente de envío de rs,
Suponemos RTT =600 s, la tasa de pérdida de paquetes debido a errores de
enlace ploss=10-3, Y el tiempo de simulación = 3,600 s: Otros parámetros son los mismos
tal como se define en la Sección 5.1. La tasa sondeada resultante y la tasa fuente-envío
se ilustran en la Figura 19.
En el estado inicial, establecemos de manera conservadora la tasa de fuente de envío
de rs de una manera controlada porque no hay conocimiento de la red está
disponible. Por lo tanto, durante el primer período de RTT, el RTT y el producto tasa
objetivo P = 84 000; partir de la ecuación (22), J = 5: Por lo tanto, K ¼ 16; D T ¼ s
28:57;
y D R ¼ 4:38 kBps: A partir de la Figura 19, en la primera fase del estado inicial, r
s
aumenta
exponencialmente 4,38-70 Kbps, es decir, la mitad de la tasa objetivo de 140
kbps. Después de un tiempo t ¼ 142:85 s;
RCP-planeta entra en la segunda fase, r
s
aumenta linealmente y llega a 140 kbps en t = 600 s:
Después de un RTT, la tasa observada r
un
y la actual tasa de pérdida de p paquetes estén disponibles. Desde
10 conexiones RCP-Planet compiten por el ancho de banda, la congestión se produce
después de t ¼ 514:29 s:
El remitente RCP-Planet retrocede y disminuye su tasa de fuente de envío de sobre la
recepción del
sondeado tarifa. Elegimos el factor de disminución de la tasa de ser 0:9, de modo que la
tasa de no caer demasiado

bruscamente. Dado que la tasa sondeado no es más alta que la tasa objetivo, r
s
no captará más
ancho de banda que la tasa objetivo. Después de la congestión es más, que comienza a
aumentar la tasa de nuevo.
En consecuencia, la tasa de envío de fuente se actualiza de acuerdo con el estado de la
red, la
tasa de fuente de envío de promedio correspondiente es 121,40 kbps, que está cerca de
la parte igual de
el ancho de banda para cada conexión, es decir, 130 kbps para la capacidad del
enlace c ¼ 1,300 kBps compartidos por 10
Conexiones RCP-Planet

5.4. Rendimiento
Utilizamos los parámetros definidos en la Sección 5.1 y asumimos RTT ¼ 300, 600,
900 s, respectivamente. La
tasa de pérdida de paquetes debido a errores de enlace p
pérdida
es 10
À5
-10
À2
: Hay 10 conexiones y cada uno
Conexión enviará 100 MB de datos. El rendimiento de procesamiento se ilustra en la
Figura 20. Nota
que el rendimiento se calcula sólo para los paquetes de datos originales de la aplicación,
FEC
paquetes redundantes no están incluidos.
RCP-Planet logra un alto rendimiento para diferentes valores de RTT y las tasas de
pérdida de paquetes debido a
errores de enlace. El rendimiento para una conexión RCP-Planet individuo es de
alrededor de 87 kbps para
RTT ¼ 300 s; 74 kbps para RTT ¼ 600 s, y 67 kbps para RTT ¼ 900 s: Considerando
FEC
redundancia no se cuenta y el tiempo de simulación es relativamente corto debido a las
limitaciones de la red
y RCP-planeta permanece en el estado inicial para un tiempo bastante largo, el
rendimiento alcanzado es alta.
Las razones que el RCP-Planet logra un alto rendimiento se pueden resumir de la
siguiente manera:
*
La tasa mecanismo discutido en la Sección 3.2 de sondeo se utiliza para capturar la
disposición
ancho de banda.
*
El tipo de fuente-envío se incrementa de una manera controlada para capturar el ancho
de banda como
rápido como sea posible y conservely.
*
El nuevo esquema de control de la frecuencia se actualiza la tasa fuente de envío de
problemas y de manera conservadora
para abordar el problema extremadamente largo retardo de propagación
Para un RTT dado, el rendimiento varía ligeramente para p
pérdida
en el rango de 10
À5
-10
À2
: Para
ejemplo, el rendimiento sólo disminuye aproximadamente 0.47 kBps de p
pérdida
¼ 10
À5
para p
pérdida
¼ 10
À2
para
RTT ¼ 900 s: Esto revela que el RCP-Planet puede recuperar la pérdida de paquetes
debido a errores de enlace
efectivamente.
5.5. Sobrecarga
Utilizamos los mismos parámetros que en la Sección 5.4 para nuestra simulación. La
sobrecarga vs resultante
tasa de pérdida de paquetes debido a errores de enlace se muestra en la Figura 21. Aquí,
la sobrecarga incluye todos los
paquetes redundantes enviadas en alta y baja prioridad.
Los gastos generales se introdujo por paquetes NIL para probar el ancho de banda
disponible y de la redundancia
paquetes para recuperar las pérdidas de paquetes, debido a errores de enlace y
congestiones. En primer lugar, se observa que la
sobrecarga es aproximadamente la misma para diferentes valores de RTT y p fijo
pérdida
: Los aumentos generales
con el aumento de p
pérdida
: Para RTT ¼ de 600 s; que aumenta de 0:189 para p
pérdida
¼ 10
À5
a 0:201 para
p
pérdida
¼ 10
À2
: Es que se requiere más redundancia La razón para recuperar las pérdidas de paquetes
por enlace
errores.
Dado que el nivel de paquetes FEC se utiliza en RCP-Planet para el tráfico de recuperar
las pérdidas de paquetes debido a
errores de enlace y congestiones, la sobrecarga es de aproximadamente 0:189, incluso
cuando p
pérdida
¼ 10
À5
: Esta cantidad de
sobrecarga se introduce principalmente por los siguientes factores:
*
Códigos Tornado requieren un poco más paquetes para recuperar un bloque FEC.
*
En el estado inicial, una mucho mayor tasa de pérdida de paquetes p
l
se elige con el fin de hacer frente a la
posibles peores condiciones de la red. Este método conservador puede incurrir en gastos
adicionales si
el canal es bueno.
*
Paquetes NIL también introducen gastos generales.
Sin embargo, esta cantidad de redundancia es bastante razonable para el nivel de
paquete FEC y es también
compensado por el alto rendimiento como se describe en la Sección 5.4 y el bloque de
alta FEC
tasa de recuperación como se describe en la Sección 5.6
5.6. FEC tasa de recuperación de bloque
Utilizamos los mismos parámetros que en la Sección 5.4 para nuestra simulación. El
bloque de FEC resultante
tasa vs tasa de pérdida de paquetes debido a la recuperación de errores de enlace se
muestra en la Figura 22.
Como se discutió en la sección 5.2, RCP-Planet intenta obtener la mayor R
blk
como sea posible. Para RTT ¼
300 s; R
blk
es 1 para p
pérdida
410
À3
, Pero cae a 0:992 para p
pérdida
¼ 10
À2
debido a la alta tasa de pérdida de paquetes
debido a errores de enlace. Para RTT ¼ 600 y 900 s, R
blk
es también en torno a 0:99: El bloque de alta FEC
las tasas de recuperación que el RCP-Planet logra se deben principalmente a dos
razones, la primera es la
liso actualización de la tasa de fuente-envío, lo que conduce a menos congestiones y por
lo tanto menos de paquetes
pérdidas, y el otro es la forma de elegir la redundancia FEC como se discute en la
Sección 5.6. Por
Por otra parte, R
blk
casi no cambia con el RTT aumentando entre 300 y 900 s. Esto también
ilustra que el RCP-Planet es tolerantes al retraso.
5.7. Justicia
Dado que a lo mejor de nuestro conocimiento, ningún régimen de control de la
frecuencia existente se ha propuesto en
Internet interplanetaria hasta el momento, sólo tenemos en cuenta la equidad
homogénea aquí, es decir, la justicia de
las 10 conexiones RCP-Planet.
Como se describe en [31], el índice de justicia basado en el rendimiento para un enlace
de cuello de botella se define como
FI ¼
½
P
N
i=1
T ð i THS
2
N
P
N
i=1
TiðÞ
2
ð30Þ
donde T i ð Þ es el rendimiento del flujo de th i y N es el número de flujos que
comparten el recurso.
FI siempre se encuentra entre 1 = N (indicando uno de ellos recibe todo el ancho de
banda y todos los demás mueren de hambre)
y 1 (que indica Obtener un mismo porcentaje de ancho de banda).
Los mismos parámetros en la Sección 5.4 se utilizan en el simulation.The resultante
equidad de paquetes vs
tasa de pérdida debido a errores de enlace se muestra en la Figura 23.
La equidad que resulta en la figura 23 muestra que la equidad es de aproximadamente 1
para diferentes
las tasas de pérdida de paquetes debido a errores de enlace. En consecuencia, RCP-
Planet conexión siempre comparte
el ancho de banda de red disponible por igual para los diferentes requisitos de aplicación
y fines
unirse a los flujos.
5.8. Ancho de banda de factor de asimetría
Ancho de banda de factor de asimetría f tal como se define por la ecuación (28) se
introduce en la Sección 4.3 para medir
la relación entre el tráfico en los canales directo e inverso para una conexión RCP-
planeta. La
ancho de banda asimetría problema se aborda ACKs a nivel de bloque en el RCP-
Planet. Si el
ancho de banda de la asimetría es menor que f; RCP-Planet no causar congestión en el
enlace inverso,
es decir, el ancho de banda de asimetría problema se resuelve para el ancho de banda de
relación de asimetría hasta f:
Los mismos parámetros en la Sección 5.4 también se utilizan en la simulación. El ancho
de banda resultante
factor de asimetría frente a tasa de pérdida de paquetes debido a errores de enlace se
muestra en la Figura 24.
Para RTT ¼ 300, 600, 900 s, f permanece aproximadamente constante en 2152 para
diferentes p
pérdida
: Esta
significa que el RCP-Planet resuelve ancho de banda asimetría hasta 2152:1 mediante el
uso de FEC a nivel de bloque
ACK. Dado que la asimetría en la capacidad de ancho de banda de los canales directo e
inverso es
típicamente en el orden de los 1000:1 en misiones espaciales [5], el ancho de banda
asimetría relación de 2152:1 es
bastante alto para los enlaces de Internet interplanetaria, por lo tanto, RCP-Planet
funciona bien en interplanetarias
Internet con gran ancho de banda asimetría. Además, ACK retardados también se
pueden utilizar para
reducir aún más el número de ACK en el enlace inverso como se discute en la Sección
4.3.
5.9. El rendimiento apagón
Cuando se detecta un apagón, RCP-Planet se mueve al Estado Blackout, como se
muestra en la Figura 3, en
Para reducir su efecto en el rendimiento de procesamiento, como se explica en la
Sección 4.2.
El rendimiento alcanzado por RCP-Planet para diferentes duraciones oscuras se muestra
en la Figura 25,
donde RTT ¼ de 600 s; p
pérdida
¼ 10
À4
, Y el apagón se produce en una posición 150 s lejos de la
receptor en el instante t = 1200 s: El rendimiento se utiliza para medir el rendimiento de
la RCP-Planeta en
condiciones oscuras. Con el fin de eliminar el efecto de las congestiones en el
rendimiento
rendimiento, sólo una conexión RCP-planeta se utiliza en la simulación. Tiempo de
simulación es
3,600 s y los otros parámetros son los mismos que en la Sección 5.1
Con el fin de investigar el rendimiento RCP-Planet en condiciones oscuras,
consideramos dos
versiones de la RCP-Planet:
*
RCP-Planet V1: Esta versión incorpora el Estado Blackout.
*
RCP-Planet V2: Esta versión no incorpora el Estado Blackout. Utiliza el enlace-
sondeo esquema introducido en SCPS-TP [32] para detectar cuando el apagón ha
terminado.
En el enlace-sondeo esquema, cuando el emisor detecta que se produce un apagón,
envía enlace-
sondeo segmentos periódicamente al receptor. Al recibir un segmento de enlace
palpación, el
receptor envía un ACK inmediatamente al remitente. Una vez recibido un ACK para el
enlace-
sondeo segmento, el remitente infiere que el apagón se ha acabado y se reanuda el envío
de paquetes de datos

Aunque los rendimientos de RCP-Planet V1 y V2 tanto disminución con el aumento de

apagón
duración B; RCP-Planet V1 siempre supera a RCP-Planet V2. Para B 4300 s, es
decir, B 52 x, la
diferencia de rendimiento entre RCP-Planet V1 y V2 aumenta con el incremento
de B: Por ejemplo,
la diferencia de rendimiento es de 0,45 kBps del B ¼ 20, pero sube 6,44 kBps en B ¼
300, lo que
está de acuerdo con el análisis en la Sección 4.2, es decir, la ganancia del estado apagón
es proporcional a B para
B 52 x: Desde B aumenta, la ganancia también aumenta.
Para B 5300 s, es decir, B 52 x, la diferencia de rendimiento entre el RCP-Planet V1 y
V2 se mantiene
aproximadamente constante. Por ejemplo, la diferencia de rendimiento es 6.42kBps
en B ¼ de 400 s;
6.52kBps del B ¼ 500 s, y 6.61kBps en B ¼ 600 s: Esto también coincide con nuestra
conclusión en la sección
4,2, es decir, la ganancia del estado apagón es proporcional a 2 x 52 x para B: Por lo
tanto, la ganancia sigue siendo el
misma para B 52 x

El problema de control de velocidad en la red interplanetaria Backbone es muy difícil

debido a los retrasos muy largos, los errores de propagación de alta enlace, ancho de
banda asimétrico, y los apagones. Debido a la falta de protocolos de control de
velocidad en la red interplanetaria Backbone, un protocolo de control de la velocidad,
RCP-Planet, se propone hacer frente a los desafíos del problema de control de la
velocidad en Internet interplanetarias. RCP-Planet se compone de dos nuevos
algoritmos, es decir Comience Estado y funcionamiento del Estado. En el estado inicial,
el tipo de fuente-envío y el número de redundancia se determinan conservadora para
que pueda hacer frente a posibles peores condiciones de la red y reducir las
posibilidades de congestión. Se propone una nueva tasa de sondeo mecanismo para
capturar el ancho de banda disponible.
Sobre la base del mecanismo de tipos de sondeo, las nuevas versiones del esquema de
control de tasa de envío de la fuente tasan sin problemas y de manera conservadora
en el estado de funcionamiento. Para recuperar las pérdidas de paquetes debido a
enlazar errores y congestiones, los códigos de Tornado se utilizan para nivel de
paquete FEC por su muy rápida codificación y decodificación. La longitud de bloque
FEC se elige adecuadamente para reducir al mínimo la sobrecarga FEC. Además, ACK a
nivel de bloque FEC se utilizan para abordar ancho de banda asimetría problemas y el
ancho de banda de factor de asimetría se introduce a la altura de lo que el grado de
ancho de banda asimetría RCP-Planet puede resolver. Aparte de eso, el estado apagón
se incorpora en RCP-Planeta para mejorar el rendimiento en condiciones oscuras.
Experimentos de simulación muestran que la RCP-Planet llega a la tarifa disponible
rápida y sin problemas utilizando el mecanismo de tipos de sondaje y el nuevo régimen
de control de la velocidad. Se logra un alto rendimiento y FEC tasa de recuperación de
bloque con una sobrecarga razonable. Múltiples conexiones RCP-Planet puede
compartir el ancho de banda disponible por igual. El Estado Blackout en RCP-Planet
siempre supera al esquema de enlace sondeo introducido en SCPS-TP [32]. Por otra
parte, resultados de la simulación también revelan que el retardo de RCP-Planet es
tolerante. Como resultado, la RCP-Planet es un protocolo de control de tasa con
diverso conjunto de algoritmos y funciones, que aborda los retos de control de la tasa
de Internet interplanetaria