Hay algunos ajustes menores, pero el campo de opciones existente hace que la mayoría de los ajustes sean un valor adicional reconocido en lugar de un verdadero cambio de protocolo.
Limpiaría las opciones, quizás las agruparía para que el análisis sea más limpio. Designaría cierto número de bits como prefijo, designando el grupo de opciones, con los bits restantes designando la opción específica. Simplifica el análisis si puede recolectar y trabajar en la granja.
Todos los algoritmos para dimensionar ventanas presentes en Linux o NetBSD deben considerarse parte del conjunto estándar. Si las opciones se refieren a ellas, entonces el sufijo debe ser lo suficientemente largo como para especificar todo en la suite estándar.
- ¿Cómo se desarrollaron las capas OSI?
- Cómo cambiar la dirección IP estática en una PC
- ¿Puedo conectarme a un proceso de host local usando mi IP pública? Si puedo, pero no puedo hacerlo, ¿cuál podría ser el problema?
- ¿Será MPLS más eficiente si se implementa utilizando redes definidas por software?
- Cómo obtener una dirección IP fija para mi administrador en Filipinas
La trayectoria múltiple definitivamente debe ser obligatoria.
Vería DTP, STP y SCTP para ver si había algo que pudiera ser rogado, prestado o robado, y si sería mejor en TCP o IP.
Probablemente agregaría una clase de opción de tipo de respuesta, luego agregaría la opción de NACKing paquetes faltantes en lugar de ACKing los recibidos.
Probablemente agregaría una clase de opción para el tipo de entrega, luego agregaría las opciones inmediata (sin almacenamiento en búfer), no confiable (el sistema actual), transaccional (donde los paquetes se clasifican pero no se entregan) y finaliza la transacción (donde se entregan los paquetes clasificados y debe ser reconocido por la aplicación). Una transacción, aquí, significa lo mismo que en la teoría de la base de datos: todo se entrega certificado o nada. Para evitar que esto sea una vulnerabilidad, necesitaría una ventana de espacio y una ventana de tiempo, donde exceder cualquiera de los dos resultados hace que la transacción finalice y los datos se eliminen.
El campo que se usó para prioridad y ahora se usa para la clasificación de paquetes puede ser un poco pequeño. Las opciones son lentas para buscar, por lo que este debe ser un campo de posición fija, pero me gustaría tener suficiente espacio para dividir el clasificador en una jerarquía de dos o cuatro niveles. De esa manera, podría tener un control más fino sobre el manejo de paquetes. También podría admitir el nivel 5 del modelo OSI, ya que tendría una manera de definir una sesión en un protocolo en un paquete de servicios integrados, y sería capaz de realizar un enrutamiento de nivel 5. Esto sería casi tan bueno como el enrutamiento de nivel 7, pero a una fracción de la potencia de procesamiento.
Puede haber una forma de codificar la información de sesión adecuada en TCP. Estoy pensando en cómo podría hacerlo de manera eficiente, pero sigo dando vueltas para tener un túnel de capa 4 que se encargue de la información de enrutamiento y ponga los datos en la capa 5. No veo cómo hacer esto de alguna manera eso reduce los gastos generales, sin embargo.
