Modelo Conceptual para QoS

IMPORTANTE: Despues de hablar con Eukeni, lo de QoS no es para la red HLT sino para la red FELIX. La explicacion de como funcionan las PriorityQueues sigue siendo valida, pero la mayoria de las otras cosas NO.

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

Topology (with new contr&config traffic)

Looking in IS:

  • What are the sw-ctrl-core-usa-* core switches (looking in IS)?
  • What are the sw-data-cal-* swithches for calibration?
  • I see switches for Monitoring and Calibration. Other traffic is also control, configuration and histograming?
  • ROS servers still have a ToR for the ctrl network? (the sw-ctrol-ros-*) same for the SFOs
  • What are the sw-ctrl-hltsv-* switches?

Traffic flows

We distiguish the following kinds of traffic:

  1. Data: Event fragments. Mainly from ROS-> TPUs in burst. Also ACKs from TPU->ROS
  2. Monitoring: statistics sent from ROS, HLTSV and TPUs to ONL machines (IS servers, PBeast??) ????
  3. Histograming: Is this the same as Monitoring (statistics is histograms+scalar values)?
  4. Calibration: From pc-tdaq-calib-* to ??? There is also sw-ctrl-cal and sw-data-cal
  5. Control: from ??? to any server (TPUs, HLTSV, ROS, and also other ctrl nodes)
  6. Configuration: from ??? to any server (TPUs, HLTSV, ROS, and also other ctrl nodes)
Looking at IS data, how can we distinguish which are the rates for each flow?

We will focus on the effect of joining these flow in the following queues (the effect on the ctrl ToRs is not interesting):

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.

DEVS Model

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. Verificar que da resultados esperados
  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 completa. (ver diagrama abajo)
  4. Implementar routing. Los nuevos nodos tienen todo tipo de patrones de comunicación ( DCM->Histograming, Cntrl->DCM, ctrl->histogram, etc, etc ). O sea, casi que cualquier nodo puede hablar con cualquiera.
    Por eso creo que hay que tener una manera de generar y rutear esos paquetes mucho mas flexible de lo que tenemos ahora. Tal vez se puede usar lo que hice de flows o algo así (que de paso pueden venir bien a la hora de taggear en las priority queues).
    1. Para una primer iteración vos a intentar aplazar esa tarea lo mas posible. Esto se puede hacer asumiendo que el foco es ver como los paquetes de control afectan el trafico de los datos. En ese sentido no es necesario generar tal cual el trafico de control, sino que en los puertos donde van los datos agregar nuevo trafico de control.
      Una opcion es que los generadores emitan paquetes de control directo en cada puerto y luego se descarten (eso es facil de configurar porque se puede leer de NETIS el trafico por puerto). Tampoco es necesario agregar nada nuevo de ruteo. Pero en este caso se pierde la correlacion cuando un paquete llega al core switch y pasa al ToR. Para resolver eso de manera simplificada se puede hacer que el core switch rutee los paquetes de control de forma aleatoria hacia los ToR (y el ToR descarta los paquetes de control).
  5. 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
  6. 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-02

Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r4 - 2016-09-05 - 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