Modelo Conceptual para QoS en la red Felix

Conceptual Model (Conceptual framework)

online: https://www.draw.io/#G0B0Spz4YE9z7_RUdOZFI5M2tQdjg

View of the switch

This is the "tipical" view of a switch, only that instead of just a queue there is PriorityQueues module.
Note that we model egress queues (and not the ingress queues) because the priority queues are implemented in egress ports. Thus, the ROUTING (selection of output port) should be applied BEFORE the queueing.
The Link Transport Delay is the one that applies the "cable delay" based on the link capacity (ej: 40 Gbps). We put it here to stress the fact that a single packet can be sent at a time and the unqueuing times are given by the link speed.

Priority Queues

PriorityQueues module view. Process for each incomming packet

We will model only egress port queues as priority queues apply to egress ports.

  • Marking: Reading any of the packet properties, it assigns a TAG to the packet. T
  • Priority Queue Select: It maps each TAG to one of the N queues.
  • N Priority Queues:
    • shared static buffer: all the queues have a static buffer size. The total buffer size for an egress port is divided equally among all queues (thus, each priority queue has a fixed buffer size)
  • Scheduling: WRR

What are we NOT modeling

  1. Ingress Ports: we will only model egress ports, as the priority queues are implemented in egress ports.
  2. Loss-less mode: porque depende de la interaccion entre ingress/egress queues, y en caso de alcanzarse la capacidad de las ingress queue se envia un pause frame al siguiente hop. (no tenemos modelado y no se van a usar pause frames en TDAQ)
  3. UC and MC queues: ¿Que son? En total serian 16 priority queues: 8 UC y 8 MC. Solo modelamos una de esas
  4. Strict Priority Scheduling (SPS): "Does not serve any WRR queue until the SPS is empty"
  5. Configurable buffer limits: Brocade has a shared buffer for all priority queues. But it allows to configure more/less percentage of the buffering capacity to certain queues. To start with, we will model only equal capacity in all queues
  6. Rate limiting: Brocade has a module which applies rate limiting which we will not model
  7. SFOs: where not included in the previous model and would require programming the SFO and PU message passing.

Tasks

En la charla con Rodri definimos algunas cosas sobre el modelo y las tareas.

Algunas tareas:

  1. Revivir el modelo de HLT (el de examples/Matias/ATLAS-TDAQ ). Hay que hacerlo compilar con los nuevos cambios y ver que funciona como esperamos.
    1. Esto YA NO VA MAS, es para la red Felix.
  2. Implementar priority queues en los switches (como esta explicado arriba)
    1. En ppio utilizando n priority queues (implementacion con VDEVS)
    2. El marcado resolverlo de la manera mas simple: tal vez que las fuentes emitan con una determinada marca (flowID?)
  3. Implementar los nuevos nodos (fuentes de paquetes). Hay que agregar los hosts, racks y switches de ONL, ctrl&config, histograms, etc.). Esto es trivial, la complejidad esta en al configuración (ver punto 5)
    1. Esto es configurar nuevos nodos segun la topologia
  4. Topologia configurable: La topologia que se va a usar no esta nada definida, por lo que la simulacion deberia ser muy facil de cambiar a otra topologia. Hoy la topologia esta dada por como se conectan los modelos y los VDEVS.
  5. Implementar routing. Si la topologia va a cambiar, el routing tambien deberia ser flexible. Hoy el routing se hace haciendo cuentas en los VDEVS indexer (ej: (inIndex % nDCMs) % nROS).
  6. Configuración de los nuevos nodos. ¿Como es el rate y patrón/distribución del trafico que generan esas aplicaciones?¿Con que nodos se comunican y con que frecuencia con cada uno?
    Esto no lo sabemos nosotros ni Eukeni. Hay que leerlo de las métricas de NETIS (que son muy poco programer-friendly, no es IS ni PBeast, estas para sacar valores hay que hacerlo casi a ojo). Por lo que vimos muy rapidamente son muy dispares, algunos dias no hay trafico, por ratos hay mucho uso, no todos los nodos son iguales (por ejemplo los nodos de monitoring de los moun es mucho mas activo que el de monitoring de CTP).
    Yo creo que vamos a tener que analizar esas métricas reales y ahí decidir como las metemos en el simulador. Se me ocurre que podemos tener que varios esceanarios (configuraciones) y probar algunos
  7. Busqueda de parámetros. Una vez que esta todo modelado, hacer lo que quiere Eukeni: buscar cuales son los parámetros que hay que usar en los switches para que el trafico ande como se espera.
Especificaciones puntuales del Brocade ICX 7250: Some details here

-- MatiasAlejandroBonaventura - 2016-09-06

Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r1 - 2016-09-06 - MatiasAlejandroBonaventura
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright &© 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback