Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Notificación de congestión cuantificada del centro de datos (DCQCN)

El acceso directo de memoria remota (RDMA) proporciona una alta transferencia de datos y una latencia ultrabaja, con una baja sobrecarga de CPU, algo necesario para las aplicaciones de centros de datos modernos. RDMA se implementa mediante el protocolo RoCEv2, que se basa en el control de flujo basado en prioridades (PFC) para habilitar una red sin caídas. La notificación de congestión cuantificada del centro de datos (DCQCN) es un esquema de control de congestión de extremo a extremo para RoCEv2. Junos admite DCQCN al combinar ECN y PFC para superar las limitaciones de PFC y admitir Ethernet sin pérdidas de extremo a extremo.

Descripción de DCQCN

El control de flujo basado en prioridades (PFC) es una función de transporte y alivio de congestión sin pérdidas que funciona proporcionando un control de flujo granular a nivel de vínculo para cada punto de código IEEE 802.1p (prioridad) en un vínculo Ethernet dúplex completo. Cuando el búfer de recepción en una interfaz de conmutador se llena hasta un umbral, el conmutador transmite una trama de pausa al remitente (el par conectado) para detener temporalmente al remitente de transmitir más tramas. El umbral de búfer debe ser lo suficientemente bajo como para que el remitente tenga tiempo de dejar de transmitir tramas y el receptor pueda aceptar las tramas que ya están en el cable antes de que el búfer se desborde. El conmutador establece automáticamente umbrales de búfer de cola para evitar la pérdida de tramas.

Cuando la congestión obliga a pausar una prioridad de un vínculo, todas las demás prioridades del vínculo siguen enviando tramas. No se transmiten únicamente las tramas de la prioridad en pausa. Cuando el búfer de recepción se vacía por debajo de otro umbral, el conmutador envía un mensaje que inicia el flujo de nuevo. Sin embargo, dependiendo de la cantidad de tráfico en un vínculo o asignado a una prioridad, pausar el tráfico puede provocar congestión en el puerto de entrada y propagar la congestión por la red.

La notificación de congestión explícita (ECN) permite la notificación de congestión de extremo a extremo entre dos puntos de conexión en redes basadas en TCP/IP. Los dos puntos de conexión son un emisor habilitado para ECN y un receptor habilitado para ECN. Debe habilitar ECN en ambos puntos de conexión y en todos los dispositivos intermedios entre los puntos de conexión para que ECN funcione correctamente. Cualquier dispositivo en la ruta de transmisión que no admita ECN interrumpe la funcionalidad de ECN de extremo a extremo.

ECN notifica a las redes sobre la congestión con el objetivo de reducir la pérdida y el retraso de paquetes haciendo que el dispositivo de envío disminuya la velocidad de transmisión hasta que la congestión desaparezca, sin perder paquetes. RFC 3168, La adición de notificación de congestión explícita (ECN) a IP, define ECN.

DCQCN es una combinación de ECN y PFC para admitir Ethernet sin pérdidas de extremo a extremo. ECN ayuda a superar las limitaciones de PFC para lograr Ethernet sin pérdidas. La idea detrás de DCQCN es permitir que ECN controle el flujo al disminuir la velocidad de transmisión cuando comienza la congestión, minimizando así el tiempo que se activa PFC, lo que detiene el flujo por completo.

El funcionamiento correcto de la DCQCN requiere equilibrar dos requisitos contradictorios:

  1. Asegurarse de que PFC no se active demasiado pronto, es decir, antes de darle a ECN la oportunidad de enviar retroalimentación de congestión para ralentizar el flujo.

  2. Garantizar que PFC no se active demasiado tarde, lo que provoca pérdida de paquetes debido al desbordamiento del búfer.

Para cumplir los requisitos clave anteriores, calcule y configure correctamente los tres parámetros importantes siguientes:

  1. Headroom Buffers—Un mensaje de pausa enviado a un dispositivo ascendente tarda algún tiempo en llegar y surtir efecto. Para evitar caídas de paquetes, el remitente de PAUSE debe reservar suficiente búfer para procesar cualquier paquete que pueda recibir durante este tiempo. Esto incluye los paquetes que estaban en vuelo cuando se envió la pausa, así como los paquetes enviados por el dispositivo ascendente mientras procesa el mensaje de pausa. Puede asignar búferes de margen por puerto y por prioridad fuera del búfer compartido global. Puede controlar la cantidad de búferes de margen que se asignan para cada puerto y prioridad mediante los parámetros MRU y longitud de cable del CNP. Si ve caídas menores de entrada incluso después de activar PFC, puede eliminar esas caídas aumentando los búferes de margen para esa combinación de puerto y prioridad.

  2. PFC Threshold: este es un umbral de entrada. Este es el tamaño máximo al que puede crecer un grupo de prioridad de entrada antes de que se envíe un mensaje de pausa al dispositivo ascendente. Cada prioridad de PFC tiene su propio grupo de prioridad en cada puerto de entrada. Los umbrales de PFC se establecen por grupo de prioridad en cada puerto de entrada. Hay dos componentes en el umbral de PFC: el PG MIN umbral y el PG shared umbral. Una vez PG MIN que se alcanzan los PG shared umbrales para un grupo de prioridad, se genera PFC para esa prioridad correspondiente. El conmutador envía un mensaje RESUME cuando la cola cae por debajo de los umbrales de PFC.

  3. ECN Threshold: este es un umbral de salida. El umbral ECN es igual al valor de nivel de llenado inicial de WRED. Una vez que una cola de salida supera este umbral, el conmutador inicia el marcado ECN para los paquetes de esa cola. Para que la DCQCN sea efectiva, este umbral debe ser menor que el umbral de PFC de entrada para garantizar que PFC no se active antes de que el conmutador tenga la oportunidad de marcar los paquetes con ECN. Establecer un nivel de llenado WRED muy bajo aumenta la probabilidad de marcado ECN. Por ejemplo, con la configuración predeterminada de búfer compartido, un nivel de inicio-llenado WRED del 10 por ciento garantiza que los paquetes sin pérdida tengan una marca ECN. Pero con un nivel de llenado más alto, la probabilidad de marcado ECN es menor. Por ejemplo, con dos puertos de entrada con tráfico sin pérdida al mismo puerto de salida y un nivel de llenado inicial WRED del 50 %, no se producirá ninguna marca ECN, ya que primero se cumplirán los umbrales de PFC de entrada.

Configuración de DCQCN (Junos OS)

Para habilitar DCQCN, configure ECN y PFC para un flujo de tráfico.

  1. Configure clasificadores para el tráfico ROCEv2 y para los paquetes de notificación de congestión (CNP). Por ejemplo:
  2. Configure ECN en el puerto de salida para un flujo sin pérdidas. Por ejemplo:
  3. Configure PFC en el puerto de entrada para el mismo flujo sin pérdida. Por ejemplo:
  4. Configure los búferes compartidos. Por ejemplo:
    Nota:

    Debe seguir estas reglas para confirmar la configuración en plataformas que ejecutan Junos OS:

    • Debe configurar las tres particiones de entrada o ninguna.

    • Debe configurar las tres particiones de salida o ninguna.

    • La suma de la configuración del búfer compartido de entrada para todas las particiones debe ser del 100 %.

    • La suma de la configuración del búfer compartido de salida para todas las particiones debe ser del 100 %.

  5. Configure clases de reenvío y asigne colas. Por ejemplo:
  6. Verifique su configuración. Por ejemplo:
  7. Confirmar su configuración.

Configuración de DCQCN (Junos OS evolucionado)

Para habilitar DCQCN, configure ECN y PFC para un flujo de tráfico.

  1. Configure clasificadores para el tráfico ROCEv2 y para los paquetes de notificación de congestión (CNP). Por ejemplo:
  2. Configure ECN en el puerto de salida para un flujo sin pérdidas. Por ejemplo:
  3. Configure PFC en el puerto de entrada para el mismo flujo sin pérdida. Por ejemplo:
  4. Configure los búferes compartidos. Por ejemplo:
    Nota:

    Debe seguir estas reglas para confirmar la configuración en plataformas que ejecutan Junos OS Evolved:

    • Debe configurar las tres particiones de entrada.

    • La suma de la configuración del búfer compartido de entrada para todas las particiones debe ser del 100 %.

    • Para las particiones de búfer con y sin pérdida, los porcentajes de partición de búfer de entrada y salida deben ser iguales.

    • QFX5000 conmutadores que ejecutan Junos OS Evolved no tienen un grupo de servicios dedicado para el tráfico de multidifusión debido a limitaciones de hardware, por lo que multidifusión tráfico utiliza búferes compartidos del grupo de servicios con pérdidas.

    La configuración dynamic-threshold de la partición del búfer de entrada sin pérdida es opcional. ECN utiliza esta opción para el cálculo del umbral en colas sin pérdida. Si no configura esta opción, dynamic-threshold utilizará su valor predeterminado de 7.

  5. Configure clases de reenvío y asigne colas. Por ejemplo:
  6. Verifique su configuración. Por ejemplo:
  7. Confirmar su configuración.