En la reunion con Eukeni vimos algunas posibles opciones para implementar la red de FELIX para Phase I. Aca algunas ideas de como encarar la simulación, posibles soluciones y dificultades que se me ocurren.

Requerimientos para la simulación

Lo que le gustaria a Eukeni resolver con simulación

1. Como asignar las prioridades a cada flujo de datos. Que porcentajes de cada link a cada flujo? Requerimientos minimos de BW de cada flujo?
2. Sizing de la red (servidores, links, etc). En particular, cuandto links de 100Gbps son necesarios para agregar los de 40Gbps?
3. Cuanto buffering seria necesario en cada nodo.
4. potenciales cuellos de botella
5. Mas adelante: evaluar diferentes opciones de "Traffic shaping" para evitar descartes (en caso de usar Ethernet).

Preguntas pendientes

1. Respecto al Dataflow, como estan relacionado un FelixServer con un SWROD? 1 Felix envia a 1 SWROD o 1-many?
   Rta: En gral 1:1, para algunos FLX 2:1 (ver reunion con Eukeni )
2. Los FelixServers va a enviar fragmentos en bursts. Estos bursts ademas van a estar sincronizados en todos los FelixServers? (o sea: un server va a mandar todos los fragmentos que recibe. Pero ademas, van a mandar todos los servidores Felix al mismo tiempo, ej:cada 25us )
   Rta: si, en ppio van a ser sincronizados.
3. Como es el routing de cada tecnologia: Trill, SBP, Ininiband, Omnipath, SND? Es correcto asumir el uso equitativo de los links (Ej: hashes) y shortest path?
   Rta: Ver abajo cada tecnologia y la discusion del ruteo. Para todas las tecnologias un src<-->dst siempre elige el mismo path, y como se comunican 1:1 no es tan facil garantizar igual uso de los links. Si los FLX tiene 2 NICs de 40Gbps, no necesariamente se van a poder usar las 2 por igual (ver reunion con Eukeni ,#NICs per FELIX)
4. Para cada sistema: FelixData, DCS, Mon, Cal, Ctrl, Config, DCS. Y para cada direccion (Felix->Sistema y Sistema->Feliz), hay que definir la intensidad del trafico:
   1. promedio de bps.
   2. promedio de paquetes/fragmentos/eventos por segundo? (o bien tamaño promedio)
   3. distribución / ¿en bursts?

Rta: Para la mayoria se puede sacar la info que hay ahora. No escalan con la luminosidad como DAQ. Si tal vez crezcan un poco.

Estrategia de simulación

¿Cual es el nivel de abstracción correcto para responder estas preguntas?

Se me ocurre que con un modelo de colas (complejo con prioridades, jorks, joins, diferentes politicas de ruteo, etc) alcanza para responder todas las preguntas (que tienen que ver con utilizacion, capacidad de buffers, cantidad de nodos necesarias, etc).
Con un nivel de abstracción mayor, ese sistema de cola se puede analizar tambien con MVA (justamente MVA puede tratar con modelos multiclass).
Obviamente eso se me ocurre porque estuve leyendo y probando JMT. Pero seria una buena excusa para implementar esas cosas en PowerDEVS para despues ir a un modelo hibrido, mitad discreto mitad MVA. ¿será posible?

Modelo Discreto

En principio cualquiera de las topologias creo que se podria representar en JMT: los nodos (FELIX, DCS, Monitoring) serian fuentes que generan trabajos. Cada nodo generaria trabajos de clases diferentes, que justamente JMT tiene el concepto de clase para diferenciar en los nodos como tratar cada clase (algunas se procesan mas rapido, tiene diferentes prioridades, ruteo, politicas, etc). Los switches son queue+server con buffers finitos y X capacidad de procesamiento segun la velocidad del link y la clase de flujo.
En nuestro caso, las clases serian: 1) Fragmentos (se rutean FELIX-->SW ROD, se generan en bursts, etc). 2) DCS (muy alta prioridad, baja generacion, ruteados DCS<->Felix 3) Ctrol&Conf 4) Monitor&Calibrartion

Complicaciones con JMT
La principal complicación que se me ocurre para modelarlo en JMT es definir la topologia y ruteo, porque no tiene una configuración central. ¿Como se hace para tener una topolofia leaf-spine con tantos nodos? Poner switch por switch en el modelo a mano es un dolor de huevos. Lo mismo parametrizarlo uno por uno.
Despues hay cosas de customizcion mas especifica, como por ejemplo hacer que todos los FELIX generen fragmentos en el mismo momento (bursts).
Esas cosas justificarian no implementar en JMT sino en PowerDEVS.

Complicaciones con PD

En PD podemos hacer que los modelos se comporten como querramos. Lo malo es que hay que implementarlos, pero la mayoria de esto (generadores, colas, servidores, politicas de balancing, etc) ya lo tenemos masticado.

Algunas cosas que se me ocurre pueden ser complicadas con PD:

1) "clases" de trafico: pensar como definir y configurar los diferentes tipos de tráfico. Algo como lo que tiene JMT, pero hay que pensar como implementarlo para que sea facil de configurar. En JMT se define una clase (ej fragmentos), pero después hay que ir modelo por modelo y decirle como tratar a esa clase en cada modelo (ej: procesarlo en X tiempo, asignarle X prioridad, etc). En PowerDEVS tenemos que pensar como hacer que esa configuración sea lo mas simple posible (que todos los switches asignen 10% de ancho de banda al trafico del DCS, 80% a fragmentos, etc). No tenerlo hardcodeado en C++ ( if(FLOW==FRAGMENT) { ..})

2) Ruteo: algo importanticimo para las topologias de red va a ser como resolver el tema del ruteo del trafico. En nuestro modelo de TDAQ lo teníamos hardodeadisimo porque había un solo camino posible (DCM-->ROS, ROS->DCM). En estas topologias vamos a tener diferentes flujos, cada uno saliendo de diferentes nodos, llendo a diferentes destinos y con diferentes posibles caminos.
En JMT se pueden definir politicas de ruteo por flujo en cada nodo (Round-robin, JSQ, 10% para aca-90%para alla, etc). Esas van bien para despues poder hacer la traduccion a un modelo compatible con MVA. Pero hay que configurar cada modelo uno por uno para cada flujo (cada uno de los XXX switches que va a haber, pensando por que puertos puede salir cada flujo).
Hay que pensar muy bien como queremos implementar esto en PD para que:

1) sea facil de configurar y modificar (algo a nivel global, no modelo por modelo)
2) respete el ruteo real de varias topologias y tecnologias
3) se pueda traducir después a MVA.

Una opcion es implementar los algoritmos de ruteo reales (learning bridge, Trill, lo que sea que haga OMNET, etc), pero eso no va a ser facil de traducirlo a algo de MVA y es costoso de implementar.
Otra es tener tablas de ruteo estaticas, pero hay que definirla modelo por modelo, flujo por flujo (¿Se puede safar de eso?), que se ajusten a lo que cada protocolo resolvería. Hay que resolver cuando se utilizan multiples links para un mismo destino-fuente (tablas de hash, ECMT en SBP, flexible en SDN) .

Cosas relacionadas con SDNs? (tengo entendido que el ruteo en SDNs se define con reglas, tal vez se pueda hacer algo asi para DEVS).

Como rutea cada protocolo:

1. Trill:
2. SBP: "The choice as to which ECMT path will be used is therefore an operator assigned head end decision while it is a local / hashing decision with IP/MPLS. ECMT tie breaking algorithm. Operator decides which services go in which ECMT paths Trees can support link aggregation (LAG) groups within a tree "branch" segment where some form of hashing occurs¨ ( wikipedia)
3. Infiniband / Omnipath / SDN: Se define por SDN. Omnipath e Infiniband tiene sus soluciones. Para Ethernet depende el paquete SDN, Eukeni evaluo uno pero que no sirve porque escala el #entradas en la tabla de ruteo con O(N²).

Ademas hay que tener cuidado, porque para elegir un camino u el otro, en gral todas las tecnologias usan el src->dst. Como 1 FLX va a hablar siempre con 1 SWROD, la ruta va a ser siempre la misma, con lo que el uso eficiente del los links no es tan obvio.

3) Topologia: hasta ahora teniamos una topologia fija dada por como conectamos los modelos en la interfaz de PD. Cuando usamos modelos vectoriales (por ejemplo los usuariamos para tener muchos switches, muchos servidores FELIX) la topologia la definiamos muy hardcodeada en los IndexMappers vectoriales (segun el indice del modelo de salida salida, va a tal modelo de entrada). Para cada conexion entonces hay un IndexMapper programado diferente (uno para ToR ->Core, otro para Core->ROS, otro para ROS->CORE, etc).
Ahora que vamos a estar trabajando con diferentes topologias, que pueden cambiar, que tal vez queremos configurarlas por parametros, creo que seria bueno cambiar como definimos la topologia (que nodos se conectan con cuales). Tal vez podemos robar algo de la sintaxis de OMNET++ o pensar otras formas de definir topologias (cosas relacionadas con SDN?).
Igual que antes, sea lo que sea, despues se tiene que poder traducir a modelos compatibles con MVA.

En fin, creo que lo que va a hacer falta es una configuracion y parametrizacion mas flexible, que permita definir todo este tipo de cosas que ahora tenemos hardcodeadas y diseminadas por todos lados.

Ideas de como especificar topologia, ruteo y clases en PowerDEVS: PowerDEVSNetworkTopology

Modelos Fluido: MVA

El modelos que tenemos que simular va a generar muchos eventos y la simulacion discreta va a andar lenta (el rate va a ser mas alto que en R2, ademas va a haber mas flujos), asique esta mas que justificado hacer un modelo fluido.

JMT te permite exportar un modelo discreto de colas a un modelo para analizarlo con MVA. En la traduccion se pierden detalles (no todo lo que se puede describir en el modelo de colas se puede expresar en MVA), asique muestra warning para esas cosas.

¿Como hacer esto en PowerDEVS?

Una opcion es traducirlo a un modelo de JMT. Pero es feo pasar a otra herramienta, mejor implementar MVA en PowerDEVS, no?

¿Que cosas se pueden traducir a un modelo de MVA y cuales se pierden en el camino? (hay que tener en cuenta para definir el modelo discreto de manera de poder traducirlo perdiendo la menor cantidad de cosas posibles). Lo que se pierda, justifica hacer el modelo hibrido. Por lo que estaria bueno poder medir la diferencia.

Para estas preguntas no se las respuestas y tengo que estudiar mas de MVA.

Algunas rtas. MVA asume las siguientes cosas que no se complirian en nuestro modelo:

1. Scheduling: Cada station trata a todas las clases por igual (no puede haber prioridades).
   Justamente algo importante que queremos es que cada flujo/clase tenga prioridades diferentes en los routers.
2. Bursts: Todo es en promedio. Para algunas cosas asume distribuciones exp. No tiene en cuenta llegadas en bursts.
   El trafico de Felix->SWROD posiblemene sea en bursts
3. Distributions: no tiene en cuenta la distribuciones de los tiempos de servicio ni llegadas. Unicamente la media.
   Eso es malo para modelar redes, porque los switches tiene tiempo de servicio constante. update: en realidad el tiempo de procesamiento no es constante, depende del tamaño del paquete, que es probable que siga una distribucion exp/nor (por ejemplo el tamaño de los fragmentos)
4. Dynamic routing: No se puede hacer ruteo segun el estado de los otros nodos.
   EJ: load balancing
5. Fork&Join: Los trabajos no se pueden ni dividir ni juntar.
   No se si nos hace falta, pero tal vez en un momento queremos hacer que varios fragmentos se transformen en 1 evento o algo asi.
6. Simultaneous: Se procesa un job a la vez, nunca en simultaneo.

-- MatiasAlejandroBonaventura - 2016-05-13